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Abstract 

This  paper  presents  the  design  and  implementation  of  PCFS,  a  file  system  that  uses 
formal  proofs  and  capabilities  to  efficiently  enforce  access  policies  expressed  in  a  rich 
logic.  Salient  features  include  backwards  compatibility  with  existing  programs  and  au¬ 
tomatic  enforcement  of  access  rules  that  depend  on  both  time  and  system  state.  We 
rigorously  prove  that  enforcement  using  capabilities  is  correct,  and  evaluate  the  file 
system’s  performance. 
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1  Introduction 


There  is  a  significant  mismatch  in  the  complexity  of  file  access  policies  prevalent  in 
large  organizations  like  intelligence  and  military  establishments,  and  the  sophistication 
of  mechanisms  currently  available  for  their  enforcement.  Policies  often  rely  on  high  level 
concepts  like  delegation  of  rights,  time-based  expiration  of  credentials,  and  attributes  of 
individuals  and  files,  whereas  the  only  available  mechanism  for  enforcing  these  policies 
in  file  systems  today  is  access  control  lists.  Translating  the  intent  of  complex  policy 
rules  to  these  low  level  lists,  and  keeping  the  latter  up-to-date  with  respect  to  changing 
credentials  requires  substantial  and  continuous  manual  effort  and  is  a  source  of  many 
policy  enforcement  errors. 

These  considerations  suggest  the  need  for  an  architecture  that  represents  the  high- 
level  intent  of  policy  rules  directly,  and  automatically  enforces  access  control.  Proof¬ 
carrying  authorization  (PCA)  [7-9]  is  a  promising,  open-ended  architecture  for  this 
purpose;  it  has  previously  been  applied  to  web  services  and  distributed  access  control  for 
physical  devices.  In  PCA,  policy  rules  are  represented  as  logical  formulas  at  a  high  level 
of  abstraction  and  enforced  automatically  with  proofs.  However,  during  each  access  to 
a  resource,  a  logical  proof  that  establishes  relevant  access  rights  for  the  calling  process 
must  be  verified.  This  is  a  slow  process  that  takes  tens  or  hundreds  of  milliseconds, 
making  the  architecture  infeasible  for  a  realistic  file  system. 

This  paper  presents  the  design  and  implementation  of  a  file  system  that  adapts 
PCA  to  provide  direct  and  efficient  enforcement  of  complex  access  policies.  Like  PCA, 
access  in  the  file  system  depends  on  proofs,  and  hence  we  call  it  the  Proof- Carrying  File 
System  (PCFS).  To  be  precise,  however,  access  requests  in  PCFS  do  not  actually  carry 
proofs  in  them  as  they  do  in  PCA.  Instead,  proofs  are  verified  by  a  trusted  program  in 
advance  of  access,  and  exchanged  for  capabilities  that  are  used  to  authorize  access.  By 
combining  proofs  and  capabilities  in  this  manner,  PCFS  retains  PCA’s  high-level  policy 
enforcement,  without  the  bottleneck  due  to  verification  of  proofs  at  the  point  of  access. 

Briefly,  PCFS  works  as  follows.  The  access  policy  is  represented  as  a  set  of  logical 
formulas  and  distributed  to  users  in  the  form  of  digital  certificates  signed  by  policy  ad¬ 
ministrators.  A  user  constructs  formal  proofs  which  show  that  the  policy  entails  certain 
permissions  for  her.  Each  proof  is  checked  by  a  trusted  proof  verifier  which  gives  the  user 
a  signed  capability  in  return.  This  capability,  called  a  procap  (for  proven  capability), 
can  be  used  repeatedly  to  get  authorized  access  to  the  file  system.  A  capability  can  be 
checked  in  a  few  microseconds.  As  a  result,  file  access  in  PCFS  is  very  efficient.  Another 
merit  of  exchanging  proofs  for  capabilities  in  advance  of  access  is  that  the  implemen¬ 
tation  factors  into  two  parts  that  interact  via  capabilities  only:  (a)  the  front  end  that 
deals  with  policies,  proofs  and  generation  of  capabilities,  and  (b)  the  backend  that  uses 
capabilities  to  authorize  access  and  perform  I/O.  Indeed  the  PCFS  backend  is  indepen¬ 
dent  of  the  logic  used  in  the  front  end,  and  it  can  be  used  with  any  policy  infrastructure 
that  produces  compatible  capabilities. 

Besides  the  fact  that  PCFS  is  the  first  implementation  of  a  file  system  that  uses 
logic  for  rigorous,  automatic,  and  efficient  policy  enforcement,  we  believe  that  our  work 
makes  three  technically  challenging  contributions.  The  first  contribution  is  an  expressive 
logic  for  writing  policies,  called  BL,  which  allows  a  novel  combination  of  user-defined 
predicates,  predicates  that  capture  the  state  of  the  system,  and  rules  and  credentials 
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that  are  valid  only  in  stipulated  intervals  of  time.  The  latter  two  allow  representation 
of  policy  rules  that  depend  on  file  meta  data  (like  extended  attributes),  as  well  as  rules 
that  expire  automatically. 

Second,  we  develop  an  end-to-end  enforcement  mechanism  for  such  rich  policies. 
This  is  non-trivial  because  constraints  about  time  and  system  state  that  occur  in  logical 
formulas  must  also  be  reflected  in  proofs,  and  subsequently  in  capabilities  that  are  used 
for  enforcement.  For  this  reason,  capabilities  used  in  PCFS  are  conditional  on  the  time 
of  access  and  the  prevailing  system  state.  In  addition  to  the  implementation,  we  prove 
a  theorem  which  shows  that  enforcement  using  capabilities  is  sound  with  respect  to  a 
PCA-like  enforcement  where  proofs  are  checked  directly  at  each  access. 

Third,  as  opposed  to  all  existing  implementations  that  use  PCA  or  related  mecha¬ 
nisms  for  enforcement  of  policies,  PCFS  is  compliant  with  the  POSIX  file  system  call 
interface,  and  is  backward  compatible  with  existing  programs.  This  is  made  possible 
due  to  two  design  decisions.  First,  instead  of  requiring  programs  to  pass  capabilities 
during  file  system  calls,  capabilities  are  put  in  an  indexed  store  on  disk  from  where  they 
are  read  by  the  file  system  interface  (hence  existing  programs  don’t  have  to  change). 
Second,  when  a  new  file  is  created,  the  user  creating  the  file  automatically  gets  access 
to  the  file  for  a  fixed  period  of  time.  As  a  result,  programs  can  freely  create  and  use 
temporary  files,  without  requiring  administrators  to  create  policies  to  govern  them. 

The  intended  deployment  for  PCFS  is  in  file  servers  where  multiple  users  log  into 
the  same  machine  and  access  shared  files,  which  need  to  be  protected  through  complex 
rules.  Another  interesting  application  of  the  PCFS  architecture  could  be  in  situations 
where  the  storage  is  not  powerful  enough  to  verify  complete  proofs,  but  has  enough 
computational  power  to  check  the  much  simpler  capabilities  (e.g.,  in  embedded  devices). 
We  also  expect  that  this  combination  of  logic  and  capabilities  can  be  used  for  access 
control  in  other  operating  system  interfaces  besides  file  systems. 

Organization.  The  rest  of  this  paper  is  organized  as  follows.  In  Section  2  we  introduce 
the  architecture  of  PCFS  and  its  various  components.  Section  3  covers  the  logic  used 
to  represent  policies,  its  features  and  meta-theoretic  properties.  Section  4  describes  the 
front  end  of  the  file  system  including  our  implementation  of  certificates,  automatic  proof 
search,  and  proof  verification  that  creates  procaps.  Section  5  discusses  the  backend  of 
the  file  system  that  uses  procaps  to  authorize  permissions.  Section  6  evaluates  PCFS  in 
terms  of  expressiveness  and  performance.  Section  7  discusses  related  work,  and  Section  8 
concludes  the  paper. 

2  Overview  of  PCFS 

PCFS  is  implemented  as  a  local  file  system  for  the  Linux  operating  system.  It  is  based 
on  the  Fuse  kernel  module  [2] .  Technically,  PCFS  is  a  virtual  file  system  since  it  uses  an 
underlying  file  system  (ext3  in  all  experiments  reported  in  this  paper)  to  perform  I/O 
after  relevant  access  checks  are  made.  PCFS  is  mounted  using  the  command: 

$>  sudo  pcfs-main  /path/to/src  /path/to/mountpoint 

Here  /path/to/src  is  an  existing  directory  in  an  ext3  system,  and  /path/to/mountpoint 
is  an  empty  directory.  After  the  execution  of  this  command,  any  file  system  call  on 
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Figure  1:  PCFS  Workflow 


a  path  like  /path/to/mountpoint/f oo/bar  results  in  a  corresponding  operation  on 
/path/to/src/f oo/bar,  but  is  subject  to  rigorous  access  checks. 

Access  checks  in  PCFS  rely  on  a  combination  of  proof-carrying  authorization  (PCA) 
[7-9]  and  cryptographic  capabilities.  PCA  provides  the  backbone  for  enforcement  of  the 
access  policy  through  formal  logic  and  digital  certificates,  while  capabilities  are  used 
to  improve  efficiency.  We  consider  this  combination  a  novel  contribution  of  this  work, 
although  capabilities  have  been  used  in  other  settings  in  the  past  to  offset  the  cost  of 
access  checks  [6,  20,  28,  31,  32].  Capabilities  in  PCFS  are  called  proven  capabilities,  or 
procaps,  since  they  are  obtained  by  verifying  formal  logical  proofs.  A  detailed  comparison 
of  PCFS  to  existing  access  control  systems  based  on  PCA  is  provided  in  Section  7. 

Figure  1  shows  the  PCFS  workflow.  Numbers  are  used  to  label  steps  in  order  of 
occurrence.  Steps  1-6  create  and  store  procaps  which  show  that  a  user  is  allowed  certain 
permissions  in  the  file  system.  These  steps  are  performed  in  advance  of  file  access,  and 
happen  infrequently  (usually  when  a  user  accesses  a  file  for  the  first  time) .  Once  procaps 
are  stored,  they  can  be  used  repeatedly  to  perform  file  operations  (steps  7-12).  The 
solid  black  vertical  line  in  the  diagram  separates  parts  that  happen  in  user  space,  i.e., 
before  and  after  a  file  system  call  (left  side  of  the  line)  from  those  that  happen  during 
a  file  system  call  (right  side  of  the  line) . 

In  the  following  we  describe  the  steps  of  Figure  1  in  some  detail.  Briefly,  policy 
enforcement  in  PCFS  follows  the  path: 

Policy  — >  Proof  ^  Procap  ^  File  access 
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Policy  creation  (Step  1).  We  define  a  policy  as  a  set  of  rules  and  facts  which  deter¬ 
mines  access  rights.  An  access  right  is  a  triple  (/c,  f,rj),  which  means  that  user  k  (Alice, 
Bob,  etc)  has  permission  rj  (read,  write,  etc)  on  file  or  directory  /.  We  allow  different 
rules  and  facts  in  a  policy  to  be  created  by  different  individuals  called  administrators 
(this  is  necessary  to  faithfully  represent  separation  of  duty  in  many  organizations).  We 
require  that  each  administrator  write  her  portion  of  facts  and  rules  as  logical  formulas 
in  a  text  file  and  digitally  sign  the  file  with  her  private  key.  This  signed  file  is  called  a 
certificate.  In  a  concrete  sense,  therefore,  a  policy  is  a  collection  of  certificates  signed  by 
different  administrators.  Abstractly,  a  policy  is  a  collection  of  logical  formulas  that  are 
contained  in  the  certificates.  We  often  denote  this  collection  of  logical  formulas  with  the 
symbol  T.  Representing  a  policy  as  logical  formulas  as  opposed  to,  say,  natural  language 
has  the  advantage  that  its  meaning  becomes  unambiguous  through  the  logic’s  inference 
rules.  Logical  representation  is  also  amenable  to  automatic  enforcement.  PCFS  pro¬ 
vides  its  own  logic,  BL,  for  writing  logical  formulas.  BL  is  more  expressive  than  prior 
logics  designed  for  similar  purposes,  and  its  syntax  and  proof  system  are  described  in 
Section  3. 

PCFS  provides  a  command  line  tool,  pcfs-cert,  to  help  administrators  check  for¬ 
mulas  for  adherence  to  logical  syntax,  to  digitally  sign  them,  and  to  convert  them  to 
a  custom  certificate  format.  (We  could  have  used  a  standard  certificate  format  like 
X.509  [23],  but  found  it  easier  to  create  our  own  format.)  Policy  rules  and  facts  in 
practice  generally  follow  specific  templates,  and  we  expect  that  our  command  line  tool 
can  be  replaced  by  GUIs.  We  do  not  assume  a  centralized  store  for  certificates.  Instead 
they  are  distributed  to  users  to  whom  they  grant  permissions.  Typically,  some  certifi¬ 
cates  are  created  once  and  used  for  many  months  or  years,  whereas  others  are  created 
as  events  happen  in  the  system.  As  a  result  of  the  latter,  the  policy  itself  is  not  static, 
but  changes  over  time. 

Proof  generation  (Steps  2—3).  Once  certificates  have  been  created  by  adminis¬ 
trators  and  given  to  users,  the  latter  use  them  to  show  that  they  are  allowed  certain 
permissions  in  the  file  system.  The  basic  tenet  of  PCFS  (adapted  from  PCA)  is  that 
a  user  k  is  allowed  permission  g  on  resource  /  at  time  u,  if  and  only  if  the  user  can 
provide  a  formal  logical  proof  M  which  shows  that  the  policies  in  effect  (F)  entail  a  fixed 
formula  auth(A:, /,  ry,  u),  or  in  formal  notation,  M  ::  F  h  auth(A:, /,  r/,  u).  The  formula 
auth(A:,  /,  r],  u)  is  defined  in  Section  3. 

To  help  users  construct  the  proof  M,  PCFS  provides  an  automatic  theorem  prover, 
through  the  command  line  tool  pcfs-search.  This  tool  is  based  in  logic  program¬ 
ming  [27]  (see  Section  4  for  a  brief  description  of  our  approach).  Figure  1  shows  the  user 
giving  the  policy  (certificates)  to  the  proof  search  tool  in  step  2,  and  the  proof  search 
tool  returning  a  proof  in  step  3.  A  typical  proof  construction  in  PCFS  takes  several 
hundred  milliseconds.  A  salient  point  is  that  the  proof  search  tool  is  not  a  trusted 
component  of  PCFS  and  it  is  perfectly  alright  for  a  user  to  create  her  own  proof  search 
tool  or  even  use  a  heuristic-based  method  or  decision  procedure  to  construct  proofs  in 
specific  cases. 

Proof  verification  (Steps  4—5).  Once  the  user  has  constructed  a  proof  M,  this 
proof,  together  with  the  certificates  used  to  construct  it,  is  given  to  a  proof  verifier. 
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invoked  using  another  command  line  program  pcfs-verify  (Step  4  in  Figure  1).  The 
code  of  the  verifier  is  simpler  than  that  of  the  prover  and  it  must  be  trusted.  The  verifier 
checks  that  the  logical  structure  of  the  proof  M  is  correct,  and  that  all  certificates  used 
in  the  proof  are  genuine,  i.e.,  their  digital  signatures  check  correctly.  If  both  these  hold, 
then  the  verifier  gives  back  to  the  user  a  procap,  which  is  a  capability  that  mentions  the 
right  {k,f,7])  that  the  proof  grants  (Step  5).  The  procap  also  contains  some  conditions 
on  which  the  proof  depends  and  is  signed  using  a  shared  symmetric  key  that  is  known 
only  to  the  verifier  and  the  file  system  interface  (see  Section  4  for  details).  A  typical 
proof  verification  including  creation  of  a  procap  takes  several  tens  or  a  few  hundred 
milliseconds,  depending  on  the  size  of  the  proof. 

Procap  injection  (Step  6).  After  receiving  a  procap,  the  user  calls  another  command 
line  tool  which  puts  the  procap  in  a  central  store  marked  “Procap  Store”  in  Figure  1. 
This  store  is  in  a  designated  part  of  the  PCFS  file  system,  and  is  accessible  to  both  users 
as  well  as  the  system  interface.  The  system  interface  looks  up  this  store  to  find  relevant 
procaps  when  file  system  calls  are  made.  The  organization  of  the  store  is  described  in 
Section  5. 

File  system  call  (Step  7).  A  call  to  the  PCFS  file  system  is  made  through  the 
usual  POSIX  file  system  API  during  the  execution  of  a  user  program  or  through  a 
shell  command  like  Is ,  cp,  rm,  etc.  The  PCFS  backend  respects  the  standard  POSIX 
interface,  so  user  programs  and  shell  commands  don’t  need  to  change  to  work  on  it. 
However,  before  a  program  is  started  or  a  shell  command  is  executed,  the  user  must 
ensure  that  procaps  granting  the  executing  process  all  needed  permissions  have  been 
created  and  injected  using  Steps  2-6.  Alternatively,  the  program  may  be  augmented  to 
possibly  create,  and  certainly  inject,  procaps  on  the  fly. 

Procap  look  up  and  checking  (Steps  8—10).  When  a  system  call  is  made  on  a 
PCFS  file  system,  it  is  redirected  by  the  Linux  kernel  to  a  process  server  which  we  have 
written  (Step  8  in  Figure  1).  Depending  on  the  specific  operation  requested,  this  server 
looks  up  one  or  more  procaps  in  the  procap  store  (Steps  9  and  10).  The  exact  procaps 
needed  for  each  operation  vary,  and  are  listed  in  Section  5.  If  all  relevant  procaps  are 
found,  they  are  checked.  Checking  a  typical  procap  takes  only  lO-lOO/zs  (c/.  the  time 
taken  to  check  a  proof,  which  is  of  the  order  of  tens  or  hundreds  of  milliseconds).  Details 
of  procap  checking  are  presented  in  Section  4. 

Error  (Steps  11a,  12).  If  any  procap  needed  for  performing  the  requested  file  oper¬ 
ation  is  missing,  or  fails  to  check,  an  error  code  is  returned  to  the  user  program. 

File  operation  (Steps  11b,  11c,  12).  If  all  relevant  procaps  needed  to  perform  the 
requested  file  operation  are  found,  and  successfully  check,  then  the  underlying  extS  file 
system  is  used  to  perform  the  requested  file  operation  (Step  11b).  The  result  of  the 
operation  is  returned  to  the  user  (Steps  11c  and  12). 
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2.1  Implementation 

The  PCFS  implementation  can  be  roughly  divided  into  two  parts:  (a)  the  front  end, 
which  comprises  the  command  line  tools  for  creating  certificates,  constructing  proofs, 
checking  proofs  to  create  procaps,  and  injecting  procaps  into  the  central  store  (Steps  1-6 
in  Figure  1),  and  (b)  the  backend  which  handles  the  calls  from  the  Fuse  kernel  module, 
looks  up  procaps  in  the  store,  checks  them,  and  then  makes  calls  on  the  underlying  file 
system  to  perform  disk  operations  (Steps  8-llc  in  Figure  1).  The  two  parts  interact 
via  procaps  which  carry  information  from  logical  proofs  into  the  file  system’s  interface. 
The  front  end  (with  the  exception  of  the  procap  injection  tool)  is  based  in  logic,  and  the 
technical  challenge  there  has  been  the  development  of  a  well-founded  logic  (BL)  that  is 
not  only  expressive,  but  that  can  also  be  efficiently  implemented.  Our  implementation 
of  the  front  end  tools  is  written  in  Standard  ML,  and  comprises  nearly  7,000  lines  of 
code.  OpenSSL  is  used  for  all  cryptographic  operations.  Because  the  front  end  tools 
are  used  less  frequently  than  the  backend,  their  efficiency  is  also  less  of  a  concern.  The 
backend  is  the  bottleneck  for  performance  and  needs  to  be  extremely  efficient.  It  is 
implemented  in  C-|--|-  using  approximately  10,000  lines  of  code. 

3  BL:  The  Authorization  Logic 

PCFS  provides  a  logic  for  expressing  policies,  which  we  call  BL,  and  outline  in  this 
section.^  A  detailed  description  of  the  logic’s  proof  system  and  meta  theory  is  deferred 
to  Appendix  A.  BL  is  an  extension  of  first-order  intuitionistic  logic  with  two  modalities 
that  have  been  studied  in  prior  work  [5,  16,  24]:  k  says  s,  which  means  that  principal 
k  states  or  believes  formula  s,  and  s  @  [ui,U2]  which  means  that  s  holds  from  time  ui 
to  time  U2-  The  former  is  used  to  distinguish  in  the  logic  parts  of  the  policy  made  by 
different  individuals  whereas  the  latter  is  needed  to  accurately  represent  time-dependent 
rules.  The  logical  interpretation  of  k  says  s  in  BL  is  different  from  that  in  any  existing 
work.  This  new  interpretation  is  designed  to  facilitate  fast  proof  search.  In  addition  to 
these  modalities,  BL  supports  constraints,  which  are  relations  between  terms  decided 
using  external  decision  procedures  not  formalized  in  the  logic  (e.g.,  the  usual  order  < 
on  integers).  BL  also  supports  predicates  that  capture  the  state  of  the  file  system. 
Formulas  in  BL  are  denoted  using  the  letters  s  and  r.  The  syntax  of  BL  is  summarized 
below. 


Sorts 

a 

::=  principal  time  file  perm 

Terms 

t 

::=  a  u  h{ti, . . .  ,tn) 

I-Predicates 

I 

(Interpreted  Predicates) 

U-Predicates 

P 

(Uninterpreted  Predicates) 

I-Atoms 

i 

. . —  Kti , . . . ,  tjj) 

U- Atoms 

::=  P{ti,...,tn) 

Constraints 

c 

::=  ui  <  U2  \  ki  P  k2  \  ■  ■  ■ 

Formulas 

r,  s 

::=  p  i  c  rAs  rVs  rDs  T  T  \/x:cr.s  3x:a.s 
k  says  s  s  @  [ui,  112] 

'^BL  stands  for  “Binder  Logic”,  as  a  tribute  to  the  trust  management  framework  Binder  [14]  from 
which  the  logic  draws  inspiration. 
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As  in  first-order  logic,  subjects  of  predicates  are  called  terms.  They  represent  princi¬ 
pals,  files,  time  points,  etc.  Abstractly,  terms  can  be  either  ground  constants  a,  bound 
variables  v,  or  applications  of  uninterpreted  function  symbols  h  to  ground  terms.  Terms 
are  classified  into  sorts  a  (sometimes  called  types).  We  stipulate  at  least  four  sorts: 
principal,  whose  elements  are  denoted  by  the  letter  k,  time  whose  elements  are  denoted 
by  the  letter  u,  file  whose  elements  are  denoted  by  the  letter  /,  and  perm  (for  permission) 
whose  elements  are  denoted  by  the  letter  ij.  Elements  of  time  are  called  time  points, 
and  it  is  assumed  that  ground  time  points  are  integers.  In  the  external  syntax  of  the 
logic,  we  allow  clock  times  written  to  second  level  accuracy  as  yyyy:mm:dd:hh:mm:ss, 
but  internally  they  are  represented  as  integers  that  measure  seconds  elapsed  from  a  fixed 
clock  time. 

The  symbol  S  denotes  a  partial  map  ui:cji,  . . . ,  Vn-CTn  from  term  variables  to  sorts. 
The  judgment  T,  t  :  a  means  that  under  the  assignment  of  sorts  S,  term  t  is  well 
formed  with  sort  a.  (We  assume  that  the  sorts  of  all  function  symbols  and  constants 
are  specified  separately,  but  elide  the  details.) 

Predicates  in  BL  are  divided  into  two  categories:  uninterpreted  predicates,  denoted 
P,  which  are  defined  using  logical  rules,  and  interpreted  predicates,  denoted  I,  which 
capture  properties  of  the  environment.  By  environment  we  mean  the  state  of  the  file 
system,  including,  but  not  limited  to,  meta  data  contained  in  files.  The  environment 
is  reflected  in  the  logic  as  a  set  E  of  interpreted  predicates  that  hold  in  it.  We  write 
E  \=  i  to  mean  that  in  the  environment  E,  the  interpreted  atomic  formula  i  holds  (i.e., 
i  €  E).  In  practice,  we  require  a  procedure  to  decide  whether  each  interpreted  predicate 
I  holds  for  some  terms  in  the  prevailing  state  of  the  file  system  or  not.  We  assume  that 
the  state  is  volatile,  i.e.,  it  may  change  unpredictably.  We  believe  that  the  inclusion 
and  enforcement  of  such  interpreted  predicates  is  novel,  at  least  in  the  context  of  access 
control. 

Finally,  we  assume  a  syntactic  class  of  constraints,  denoted  c.  Like  interpreted 
predicates,  constraints  are  also  relations  between  terms  whose  satisfaction  is  determined 
by  decision  procedures  external  to  the  logic.  However,  unlike  interpreted  predicates, 
constraints  are  independent  of  the  state  of  the  system.  We  stipulate  at  least  two  types 
of  constraints:  ui  <  U2  capturing  the  usual  total  order  on  time  points,  and  a  pre-order 
ki  P  k2,  read  principal  ki  is  stronger  than  principal  k2.  If  ki  P  k2,  then  BL’s  inference 
rules  force  {ki  says  s)  D  {k2  says  s)  for  every  formula  s.  We  also  assume  that  there  is  a 
strongest  principal  £,  i.e.,  \=  £  P  k  for  every  k.  In  particular  {£  says  s)  D  {k  says  s)  for 
every  k  and  s.  For  this  reason  £  is  called  the  “local  authority” ,  a  principal  whom  everyone 
believes.  (The  term  local  authority  is  borrowed  from  the  language  SecPAL  [3,  10].)  A  set 
of  constraints  is  written  'L.  The  decision  procedure  for  checking  constraints  is  reflected 
in  the  logic  as  the  judgment  'I'  ^  c,  which  means  that  if  all  constraints  in  'I'  hold,  then 
so  does  c. 

3.1  Proof  System 

Next,  we  present  a  proof  system  for  BL  in  the  natural  deduction  style  of  Gentzen  [19]. 
Our  approach  is  based  on  the  judgmental  method  [12,  29],  where  a  syntactic  category 
of  judgments  (distinct  from  formulas)  is  the  subject  of  proofs  and  deductions.  Using 
the  judgmental  method  makes  the  meta-theory  of  the  logic  much  easier.  Our  technical 
presentation  closely  follows  prior  work  by  DeYoung  et  al.  done  in  the  context  of  a 
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related  logic  [16].  As  in  that  work,  we  introduce  two  judgments:  s  o  [u\,U‘2\  meaning 
that  formula  s  is  provably  true  in  the  interval  [tti,  U2],  and  k  claims  so  [m,  U2]  meaning 
that  principal  k  states  that  s  holds  from  ui  to  U2-  The  symbol  o  is  read  “during”.  The 
judgment  s  o  [u\,U2\  is  internalized  in  the  logic  as  the  formula  s  @  [ui,U2\,  whereas 
k  claims  s  o  [u\,U2]  is  internalized  as  {k  says  s)  @  [ui,  U2]- 


Judgments  J 

Sort  Map  S 

Hypothetical  Constraints  'k 

Abstract  Environment  E 

Views  a 

Hypotheses  T 

Hypothetical  Judgments 


s  o  [ni,  U2]  I  k  claims  so  [m,  U2] 

V\'.(7\  .  .  .  Vn'-O'n 
Cl  .  .  .  Cn 

Ul) ,  Ue 

Xi  :  Ji  . . .  Xn  ■■  Jn  (n  >  0) 

S;  'k;  E;  r  s  o  [m,  7/2] 


Hypothetical  judgments  (which  are  established  through  proofs)  have  the  form  S;  'k;  E;  T  - 
s  o  [ui,U2]-  T  is  the  set  of  assumed  judgments  (hypotheses  or  policy),  and  S,  'k,  and  E 
have  meanings  described  earlier,  xi, ...  ,Xn  are  distinct  names  that  refer  to  the  assump¬ 
tions  in  T.  A  novel  feature  here  is  the  triple  a  =  k,Ub,Ue  on  the  entailment  arrow,  which 
we  call  the  view  of  the  sequent.  The  view  represents  the  principal  and  interval  of  time 
relative  to  which  reasoning  is  being  performed.  It  affects  provability  in  the  following 
manner:  while  reasoning  in  view  k,  Ub,  Ue,  an  assumption  of  the  form  k'  claims  s  o  [u^,  U2] 
entails  s  o  [rt^^,rt2]  if  k'  ^  k,  u'^  <  Ub,  and  Ue  <  This  entailment  does  not  hold  in 
general.  Views  are  explained  in  greater  detail  in  Appendix  A. 

A  proof  is  represented  compactly  as  proof  term,  denoted  M.  We  write 
M  ::  S;'k;E;r  s  o  [ui,U2\  to  mean  that  M  is  a  proof  term  that  represents  a 
proof  of  the  hypothetical  judgment  that  follows  it.  For  each  deduction  rule  in  our  proof 
system,  there  is  a  unique  constructor  for  proof  terms.  Consequently,  an  entire  proof  can 
be  reconstructed  from  its  proof  term  and  the  hypotheses. 

Figure  2  shows  selected  rules  of  the  proof  system.  The  remaining  rules  are  shown  in 
Appendix  A.  As  usual,  we  have  introduction  and  elimination  rules  for  each  connective 
(marked  I  and  E  respectively).  For  a  syntactic  entity  R,  R[t/x\  denotes  the  capture 
avoiding  substitution  of  term  t  for  variable  x  in  R.  The  rule  (hyp)  states  that  the 
assumption  s  o  entails  s  o  [ui,U2]  if  u'^  <  ui  and  U2  <  u'2,  i.e.,  the  interval 

[ui,U2]  is  a  subset  of  the  interval  This  makes  intuitive  sense:  if  a  formula 

s  holds  throughout  an  interval,  it  must  hold  on  every  subinterval  as  well.  The  proof 
term  corresponding  to  this  (trivial)  derivation  is  x,  where  x  is  also  the  name  for  the 
assumption  s  o  [u'l,  U2].  The  rule  (claims)  is  similar,  except  that  it  allows  us  to  conclude 
s  o  [ui,U2]  from  the  assumption  k'  claims  s  o  [u'i,u'2\.  In  this  case,  it  must  also  be 
shown,  among  other  things,  that  k'  is  stronger  than  the  principal  k  in  the  view  (premise 
\=  k'  '^k). 

(saysl)  is  the  only  rule  which  changes  the  view.  The  notation  Tj  in  this  rule  denotes 
the  subset  of  T  that  contains  exactly  the  claims  of  principals,  i.e.,  the  set  {(x  :  k'  claims 
s'  o  [ui,U2])  £  T}.  The  rule  means  that  {k  says  s)  o  [ui,U2]  holds  in  any  view  a  if 
s  o  [ui,U2]  holds  in  the  view  k,ui,U2  using  only  claims  of  principals.  Assumptions  of 
the  form  s'  o  [u'^ ,  ^2]  eliminated  from  T  in  the  premise  because  they  may  have  been 
added  in  the  view  a  (using  other  rules  not  shown  here),  but  may  not  hold  in  the  view 
k,  Ui,U2. 
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S; £;;r  s  o  [^1,^2] 


VI/ <Ui  ^  \=  U2  <u'2 

X  ::  E;T,x  :  s  o  s  o  [ui,  U2] 


hyp 


a  =  k,  Ub,  Ue 

VI/  h%  <  Ui  \=  U2  <U2  \=  u'l  <  Ub  \=  Ue  <  U2  \=  k'  >  k 

X  ::  S;  T,x  :  k'  claims  s  o  m^]  s  o  [mi,  U2] 

M::S;^;^;r|  s  o  [m,  ^2] 

(pf_saysl  M)  ::  S;  vl/;  £;;  F  (fc  says  s)  o  [mi,  M2] 


claims 


saysl 


Ml  ::  S;  vl/;  i5;  F  Si  D  S2  o  [ui,  M2] 

M2  ::  S;  vl/;  iJ;  F  Si  o  U2]  'I'  H  Mi  <  Wi  <  w"  'I'  |=  M2  <  ^  M2 

(pf  _impE  Ml  M2  Ml  U2)  ::  S;  vl/;  iJ;  F  S2  o  [u'l,  U2] 

M  ::  S;  vl/;  _E;  F  ^Iv.a.s  o  [mi,  M2]  S  h  t  :  ct 
- 

(pf  _f  orallE  M  i)  ::  S;  vl/;  i<;;  F  — s-  s[t/v\  o  [mi,  M2] 

S  h  *  .  ,  -r  ^  h  C 


DE 


(pf  _sinj  l)  ::  S;  vl/;  E;  F  — >  i  o  [mi,  M2] 


-interl 


(pf  _cinjl)  ::  S;  vl/;  E;  F  — >  co  [mi,  M2] 


-consi 


Figure  2:  BL:  Natural  Deduction  (Selected  rules) 


(dE)  is  a  variant  of  the  common  rule  of  modus  ponens.  It  means  that  if  si  D  S2 
holds  during  an  interval  [mi,  M2])  and  si  holds  during  a  subinterval  [m'i,  M2],  then  S2  must 
hold  during  any  interval  [mi,M2],  which  is  contained  in  both.  (VE)  states  that  if  VxrcT.s 
holds  during  some  interval  [mi,M2],  then  s[t/x\  holds  during  the  same  interval  for  any 
term  t. 

The  rule  (interl)  is  used  to  establish  interpreted  predicates.  It  states  that  an  inter¬ 
preted  atomic  formula  i  is  provable  \i  E  \=  i.  The  rule  (consi)  is  similar  but  it  is  used 
to  establish  constraints. 

Meta-theory.  A  meta-theorem  is  a  theorem  about  the  proof  system  in  general.  Meta¬ 
theorems  not  only  increase  confidence  in  the  foundations  of  the  logic,  but  also  help  in 
constructing  automatic  proof  search  tools.  We  state  below  two  important  meta-theorems 
about  BL’s  proof  system:  substitution  and  subsumption.  Structural  theorems  such  as 
weakening  for  the  hypotheses  also  hold,  but  we  do  not  state  them  explicitly.  M[M' /x] 
denotes  the  capture-avoiding  substitution  of  proof  term  M'  for  the  name  x  in  the  proof 
term  M. 

Theorem  3.1  (Substitution).  Suppose  the  following  hold: 

1.  M'  ::  S;^;E;r  ^  so  [mi,M2] 

2.  M  ::  S;  vk;  E;  T,  X  :  s  o  [mi,  M2]  r  o  [m'^,  M2] 
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Then,  {M[M'/x])  ::  S;  T  ^  r  o  [u[,u'2] 

Proof.  See  Appendix  A.  □ 

Theorem  3.2  (Subsumption).  Suppose  the  following  hold: 

1.  M  ::  E]T  ^  s  o  [ui,U2] 

2.  \=  UI  <Un  and  \=  Um  <  '^2 

Then,  M  ::  E;r  s  o  [un,  Um] 

Proof.  See  Appendix  A.  □ 

3.2  Connection  to  Enforcement 

Representation  of  files  and  principals.  The  logic  BL  does  not  mandate  how  files 
and  users  are  concretely  represented.  However,  from  the  perspective  of  an  implemen¬ 
tation,  making  this  choice  is  important.  In  PCFS,  files  and  directories  are  represented 
by  their  full  pathnames,  relative  to  the  path  where  PCFS  is  mounted.  Thus,  if  PCFS 
is  mounted  at  /path/to/mountpoint,  then  the  file  /foo/bar  in  any  formula  refers  to 
the  file  /path/to/mountpoint/f  oo/bar  in  the  file  system.  Principals  are  represented 
in  one  of  two  ways:  either  as  symbolic  constants,  or  by  their  Linux  user  ids.  The  for¬ 
mer  representation  is  used  for  principals  that  do  not  correspond  to  any  real  users  (e.g., 
organizational  roles),  while  the  latter  is  used  for  principals  that  do  (e.g.,  users  that  run 
programs  and  access  files).  Permissions  are  given  on  a  per-file  (or  per-directory)  basis 
to  real  users. 

Representation  of  policy  in  BL.  If  an  administrator  k  creates  a  rule  represented 
by  formula  s,  and  puts  it  in  a  certificate  that  is  valid  from  time  ui  to  time  U2,  then  this 
rule  is  reflected  in  BL  as  the  assumption  k  claims  s  o  [ui,U2].  In  addition,  we  require 
that  each  rule  be  accompanied  by  a  unique  name  (a  string),  which  is  written  in  the 
certificate  with  the  rule.  This  name  is  used  to  refer  to  the  assumption  in  proofs.  The 
whole  policy  has  the  general  form  F  =  {xi  :  ki  claims  Si  o  [m,  u'f\\l  <i  <  n},  where  kfs 
are  administrators,  and  xfs  are  unique  names  for  the  rules  of  the  policy. 

What  should  be  proved?  We  assume  the  existence  of  one  distinguished  administra¬ 
tor,  symbolically  denoted  admin,  who  has  the  ultimate  authority  on  access.  In  order  to 
get  permission  rj  on  file  /  at  time  u,  user  k  must  prove  that  the  policy  in  effect  entails 
the  defined  judgment  auth(A:,  /,  r/,  u),  where: 

auth(k,  f,rj,u)  =  (admin  says  may (fc, /,  r/))  o  [u,u] 

may  is  a  fixed  uninterpreted  predicate  taking  three  arguments,  and  u  is  the  time  of  access 
{[u,u\  is  a  singleton  set  containing  exactly  the  time  point  u). 

When  we  start  constructing  a  proof  in  BL  at  the  top  level,  the  exact  view  a  does 
not  matter.  Further  the  set  'k  is  empty,  and  S  is  a  fixed  map  provided  externally.  To 
get  access  it  must  be  shown  that:  S;  ■;  E;r  auth(/c,  /,  rj,  u),  where  a  is  a  view  made 
of  fresh  constants,  F  is  the  policy,  u  is  the  time  of  access,  and  E  is  the  environment  at 
time  u. 
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Usually,  admin  delegates  part  of  its  authority  to  other  administrators  through  rules. 
Also,  in  most  policies,  admin  may  have  authority  over  the  predicate  may  but  not  others. 
For  this  reason,  it  is  advisable  to  keep  admin  distinct  from  the  strongest  principal 
whom  everyone  believes  on  every  predicate. 

Interpreted  Predicates.  BL  natively  supports  two  interpreted  predicates,  although 
support  for  other  predicates  can  be  added  easily.  These  two  predicates  are:  owner (/,  A:), 
which  means  that  file  /  has  owner  A,  and  hasjxattr(/,  a,  u),  which  means  that  file  /  has 
value  V  for  the  extended  attribute  user.^pcf  s.a.  Extended  attributes  beginning  with 
the  prefix  user.^pcfs.  are  specially  protected  by  PCFS  (a  special  permission  called 
“govern”  is  needed  to  change  them).  These  attributes  can  be  used  to  label  files  in  a 
secure  manner,  as  we  illustrate  in  the  following  example.  Interpreted  predicates  are 
written  in  boldface  to  distinguish  them  from  others. 

Example  1 .  We  present  a  fragment  of  a  case  study  that  uses  BL  to  model  policies  for 
control  and  dissemination  of  classified  files  in  the  U.S.  Consider  a  hypothetical  intelli¬ 
gence  agency  where  each  file  and  each  user  is  assumed  to  have  a  classification  level,  which 
is  an  element  of  the  ordered  set  confidential  <  secret  <  topsecret.  The  classification  level 
of  a  file  is  assumed  to  be  written  in  an  extended  attribute  user. ^^fpcfs. level  on  the 
file.  We  also  assume  one  distinguished  administrator  (in  addition  to  admin)  called  hr 
who  is  responsible  for  deciding  attributes  of  users  (e.g.,  giving  them  classification  levels 
and  employment  certifications). 

In  order  that  principal  k  may  read  file  /,  three  conditions  must  be  satisfied:  (a)  k 
should  be  an  employee  of  the  intelligence  organization  (predicate  employee(A:)),  (b)  k 
should  have  a  classification  level  above  the  file  (predicate  hasLevelForFile(A:, /)),  and 
(c)  k  should  get  permission  from  the  owner  of  the  file.  Let  us  assume  that  this  rule  came 
in  effect  in  2000,  and  will  remain  in  effect  till  2010.  The  following  rule  (created  by  admin) 
captures  this  intent.  For  readability,  we  omit  all  sort  annotations  from  quantifiers. 

admin  claims  V/c,  k',  f. 

(((hr  says  eniployee(/c))  A 
,  .  hasLevelForFile(A:, /)  A 

owner(/,  k')  A 

{k'  says  may(/c,  /,  read)))  D  may(/c,  /,  read)) 
o  [2000,2010] 

The  predicate  hasLevelForFile(/c, /)  may  further  be  defined  by  admin  in  terms  of 
classification  levels  of  k  and  /. 

admin  claims  V/c,  /,  /,  V . 

((has_xattr(/,  level, /)  A 
(2)  (hr  says  levelPrin(/c, /'))  A 

below(/,/'))  D  hasLevelForFile(/c, /)) 
o  [2000,2010] 

It  is  instructive  to  observe  the  use  of  the  interpreted  predicates  owner  and  has_xattr 
in  these  rules.  The  predicate  below(/,/')  captures  the  order  I  <  I'  between  classification 
levels.  We  assume  that  all  principals  believe  this  order.  Hence  it  is  stated  by  the 
strongest  principal  i. 
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(3)  £  claims  below(confidential,  secret)  o  [2000,2010] 

(4)  £  claims  below(secret,  topsecret)  o  [2000,2010] 

(5)  £  claims  below(confidential,  topsecret)  o  [2000,2010] 

As  an  illustration  of  the  use  of  this  policy,  let  us  assume  that  file  /secret. txt  is  owned 
by  Alice  (user  id  1003)  and  classified  at  the  level  secret.  Thus  the  following  must  hold 
in  the  prevailing  file  system  state  E: 

(A)  E  \=  owner(/secret.txt,  uid  1003) 

(B)  E  ^  has jxattr (/secret. txt,  level,  secret) 

Suppose  further  that  Bob  (user  id  1500)  is  an  employee  cleared  at  level  topsecret  from 
2007  to  2009,  and  that  Alice  wants  to  let  Bob  read  file  /secret. txt  from  2008  to  2009. 
This  information  may  be  captured  by  the  following  formulas  (signed  by  the  respective 
principals). 

(6)  hr  claims  eniployee(uid  1500)  o  [2007,2009] 

(7)  hr  claims  levelPrin(uid  1500,  topsecret)  o  [2007,2009] 

(8)  (uid  1003)  claims  niay(uid  1500,  secret.txt,  read) 
o  [2008, 2009] 

Let  T  denote  the  set  of  policy  rules  (l)-(8)  (with  corresponding  names  pl-p8),  and  let  S 
be  a  map  that  defines  the  constants  used  in  the  policy.  Then  using  the  rules  of  Figure  2 
we  can  show  that  there  is  a  proof  term  M  such  that  M  ::  Ti]-]E]T  (admin  says 
may(uid  1500, /secret.txt,  read))  o  [2008,2009],  if  E  satisfies  the  conditions  (A)  and  (B). 
From  Theorem  3.2  it  follows  that  M  ::  T,;-;E;T  auth(uid  1500, /secret.txt,  read, u) 
whenever  u  £  [2008,2009],  and  hence  Bob  should  be  able  to  read  /secret.txt  from  2008 
to  2009.  This  is  what  we  may  intuitively  expect  because  the  intersection  of  the  validities 
of  all  certificates  issued  here  is  exactly  [2008,2009]. 

4  PCFS  Front  End:  Proof  Search  and  Verification 

Having  discussed  the  syntax  and  proof  system  of  BL,  we  now  turn  to  its  implementation 
in  proof  search  and  proof  verification  tools.  We  start  by  describing  the  proof  search  tool 
briefly,  and  then  turn  to  the  proof  verification  tool  and  the  structure  of  procaps. 

4.1  Automatic  Proof  Search 

Even  though  users  are  free  to  construct  proofs  of  access  by  any  means  they  like,  PCFS 
provides  a  command  line  tool  called  pcf  s-search  for  performing  this  task  automatically. 
As  discussed  in  Section  3,  the  objective  is  to  prove  a  judgment  of  the  form  S;  •;  E;  F 
(admin  says  may(A:, /,  ry))  o  [u,u\,  where  u  is  the  expected  time  of  access,  and  E  is  the 
expected  environment  at  time  u.  Of  course,  in  almost  all  cases,  it  is  unreasonable  to 
expect  that  the  time  of  access  can  be  predicted  in  advance  to  the  precision  of  seconds 
(which  is  the  precision  at  which  enforcement  of  time  works  in  PCFS),  so  instead  of 
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an  exact  time  u,  the  user  provides  a  range  of  time  [ui,U2]  during  which  she  desires 
access.  Similarly,  since  the  environment  E  at  time  u  may  also  be  difficult  to  predict,  the 
environment  at  the  time  of  proof  construction  is  used  as  a  proxy.  The  prover  can  also 
be  run  in  interactive  mode,  where  it  asks  for  user  input  about  the  expected  environment 
if  it  fails  to  construct  a  proof  in  the  prevailing  one. 

The  user  must  also  provide  the  parameters  k,  /,  r]  and  the  policy  T  (in  the  form  of 
certificates  obtained  from  administrators).  The  output  of  the  tool  is  the  proof  term 
M  such  that  M  ::  T,;-]E;T  (admin  says  niay(A:, /,  77))  o  [ui,U‘2\.  By  Theorem  3.2  it 
follows  that  M  ::  T,-,-]E]r  — >  auth(A:, /,  77,  u)  for  every  u  G  [771,772],  so  this  proof  term 
M  can  be  used  for  access  at  any  time  point  in  the  interval  [771,772]. 

Proof  search  in  BL  is  in  general  an  undecidable  problem  because  BL  extends  first- 
order  intuitionistic  logic,  which  is  itself  undecidable.  However,  as  past  work  on  languages 
and  logics  for  authorization  shows  [10,  11,  14,  26,  30],  most  access  policies  in  practice 
fit  into  a  restricted  fragment  of  logic  on  which  logic  programming  techniques  can  be 
used  for  proof  construction.  Although  logic  programming  methods  work  fast,  extending 
them  from  fragments  of  first-order  logic  (where  they  are  well  understood)  to  BL’s  ad¬ 
ditional  constructs  -  k  says  s,  s  @  [771,772],  constraints,  and  interpreted  predicates  -  is 
a  challenging  task.  The  @  modality  is  particularly  difficult  to  handle  since  it  interacts 
with  all  other  connectives  of  BL  in  non-trivial  ways.  We  omit  a  description  of  the  proof 
search  method,  but  refer  the  reader  to  prior  work  for  details  [17]. 

4.2  Proof  Verification  and  Procaps 

The  proof  verifier  checks  proofs  that  a  user  constructs  and  issues  procaps  in  return. 
Since  these  procaps  can  be  directly  used  for  access,  the  proof  verifier  is  a  trusted  piece 
of  code.  Briefly,  the  proof  verifier  is  invoked  with  a  command  line  tool  pcfs-verify. 
It  is  given  as  input  the  policy  T  (in  the  form  of  signed  certificates),  the  parameters  k, 
/,  77,  and  a  proof  term  M.  The  verifier  first  checks  that  the  policy  is  correct,  i.e.,  all 
its  certificates  have  authentic  digital  signatures.  For  this,  the  verifier  must  have  access 
to  some  public  key  infrastructure  (PKI)  that  maps  public  keys  to  principals  that  own 
them.  We  use  a  simple  PKI,  with  a  single  certifying  authority  (CA)  that  certifies  all 
keys.  The  public  key  of  the  CA  is  stored  in  a  specially  protected  file  in  PCFS  itself  (see 
Section  5). 

Second,  the  verifier  checks  the  logical  structure  of  the  proof  term,  i.e.,  it  makes 
sure  that  it  is  the  case  that  M  ::  S;  •;K;F  auth(A:, /,  77, 77).  Checking  a  logical  proof 
is  mostly  standard;  it  works  on  the  observation  that  the  proof  term  (together  with 
the  policy)  is  enough  to  reconstruct  the  structure  of  the  entire  proof.  Once  this  step 
succeeds,  the  verifier  outputs  for  the  user  a  signed  capability,  which  contains  the  tuple 
{k,f,r]).  There  are  three  subtleties  here. 

1.  How  does  the  verifier  get  access  to  the  secret  key  needed  to  sign  the  procap?  (Or, 
what  prevents  users  from  accessing  the  key  and  forging  procaps?) 

2.  What  file  system  state  E  is  the  proof  checked  in?  This  is  relevant  because  it  should 
never  be  the  case  that  a  proof  successfully  checks  in  some  state  E  but  the  resulting 
procap  is  used  in  a  state  where  the  proof  verification  would  have  failed. 

3.  How  does  the  procap  reflect  the  time  interval  over  which  the  proof  is  valid? 


13 


To  address  problem  (1),  we  use  a  simple  method.  The  secret  key  is  stored  in  a  specially 
marked  file  in  the  PCFS  file  system.  The  file  system  interface  ensures  that  only  a 
specific  user  id  (called  pcfssystem)  has  read  access  to  this  file.  The  verification  tool 
pcf  s-verify’s  disk  file  is  owned  by  this  user,  and  executes  with  a  set-uid  bit.  As  a 
result,  when  a  user  invokes  this  program,  it  runs  with  pcfssystem ’s  user  id,  and  hence 
gets  access  to  this  key. 

Problem  (2)  is  addressed  by  never  checking  interpreted  predicates  during  proof  ver¬ 
ification.  Instead,  when  the  verifier  encounters  the  proof  term  pf_sinjl,  which  cor¬ 
responds  to  an  application  of  the  rule  (interl)  from  Figure  2,  the  verifier  writes  the 
interpreted  predicate  i  to  be  checked  in  the  output  procap.  This  predicate  must  then  be 
checked  by  the  file  system  backend  when  the  procap  is  used.  As  a  result,  any  interpreted 
predicates  on  which  the  validity  of  the  proof  depends  are  transferred  unchanged  to  the 
procap,  and  are  checked  in  the  state  prevalent  at  the  time  of  access  (see  Appendix  B  for 
details). 

To  address  problem  (3),  we  use  a  special  symbolic  constant  ctime,  which  has  sort 
time,  and  is  supposed  to  represent  the  actual  time  at  which  access  is  requested.  The 
verifier  tries  to  check  that  M  ::  S,  ctime:time;  •;  sT  — >  auth(/i:, /,  r/,  ctime).  Observe  that 
the  time  of  access  u  is  replaced  by  this  symbolic  constant.  During  the  verification,  many 
judgments  of  the  form  \=  ui  <  U2  are  encountered  (e.g.,  in  the  rules  (hyp),  (claims), 
(dE),  and  (consi))  where  either  'k,  ui,  or  U2  contains  ctime.  If  this  happens,  then  instead 
of  verifying  the  judgment  using  the  external  decision  procedure,  it  is  written  into  the 
output  procap.  During  file  access,  the  file  system  backend  substitutes  the  actual  time  of 
access  for  the  constant  ctime  in  the  judgment  and  checks  it  (see  Appendix  B  for  details). 

Symbolic  constants  similar  to  ctime  have  been  used  to  represent  access  policies  in 
the  past  [8,  10].  However,  in  each  of  these  cases,  the  constant  is  a  part  of  the  logic  and 
can  be  used  within  a  policy  (similar  to  our  interpreted  predicates).  In  contrast,  we  use 
the  constant  as  an  enforcement  technique  only;  time  in  the  logic  is  represented  using 
the  @  connective. 

Procap  structure.  In  summary,  a  procap  contains  four  components  {fi,  i,  C,  H),  where 

-  =  {k,  /,  rj)  is  a  three-tuple  that  lists  the  principal,  file,  and  permission  that  the 
procap  authorizes. 

-  i  is  a  list  of  interpreted  predicates  on  which  the  verified  proof  depends  (point  (2) 
above) . 

-  C  is  a  list  of  judgments  ^  \=  ui  <  U2  that  contain  the  constant  ctime,  and  on 
which  the  proof  depends  (point  (3)  above).  In  most  cases  'k  is  •. 

-  H  is  a  cryptographic  signature  over  the  first  three  components.  This  guarantees 
the  procap’s  authenticity. 

Procap  verification.  Before  admitting  a  procap,  the  file  system  backend  must  check 
not  only  its  signature  H,  but  also  the  interpreted  predicates  i  (in  the  state  prevalent 
at  the  time  of  access)  and  the  constraint  judgments  in  the  list  C  (with  ctime  substi¬ 
tuted  by  the  actual  time  of  access).  The  following  (informally  stated)  theorem  shows 
that  these  checks  guarantee  that  the  proof  in  lieu  of  which  the  procap  was  obtained 
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authorizes  the  operation  at  the  actual  time  of  access.  A  precise  formalization  of  the 
verification  procedure,  a  formal  statement  of  this  theorem,  and  its  proof  are  presented 
in  Appendix  B. 

Theorem  4.1  (Enforcement  correctness).  Suppose  that  the  verifieation  of  a  proof  term 
M  whieh  establishes  the  right  ■0  =  {k,  /,  r])  from  policy  T  results  in  a  procap  (0,  i,  C,  E). 
Further  let  E  be  a  file  system  state,  which  occurs  at  some  time  u,  and  assume  that: 

1.  For  each  i  €  i,  E  \=  i 

2.  For  each  ('h  ^  rti  <  U2)  £  C,  'I'[M/ctime]  \=  c[u/ct\me\ 

Then,  M  ::  S;  •;  E;  E  auth(/c,  /,  r/,  u) . 

Example  2.  At  the  end  of  Example  1,  we  constructed  a  proof  term  M  which  estab¬ 
lished  E-,T  (admin  says  may(uid  1500, /secret. txt,  read))  o  [2008,2009],  where  E  was 
required  to  satisfy  the  two  conditions  (A)  and  (B).  If  we  give  this  proof  term  to  our 
proof  verifier,  the  resulting  procap  has  the  structure  (0,  i,  C,  H),  where 

-  0  =  (uid  1500, /secret. txt,  read) 

-  i  =  owner(/secret.txt,  uid  1003),  has_xattr (/secret. txt,  level,  secret) 

-  C  =  .\=  2008:01:01:00:00:00  <  ctime,  •  ^  ctime  <  2009:12:31:23:59:59 

The  predicates  in  list  i  imply  that  the  procap  is  valid  only  in  a  state  where  /secret. txt  is 
owned  by  Alice,  and  it  has  extended  attribute  user. 0:pcfs. level  set  to  secret.  These 
correspond  exactly  to  conditions  (A)  and  (B)  from  Example  1,  and  are  necessary  for  the 
proof  term  M  to  be  valid.  The  list  C  means  that  the  time  of  access  ctime  must  lie  in 
the  interval  [2008,  2009],  which  is  also  what  we  may  expect  from  the  policy  rules. 

Certificate  Revocation.  A  revocation  refers  to  the  withdrawal  of  a  policy  rule  or  fact 
after  it  has  been  created  but  before  it  expires.  Revocations  are  an  issue  for  enforcement 
because  proofs  and  procaps  depending  on  a  revoked  statement  may  already  have  been 
generated.  There  are  two  simple  ways  to  enforce  revocations  using  procaps,  both  of 
which  we  describe  briefly.  (The  current  implementation  of  PCFS  does  not  implement 
revocation,  but  either  of  these  methods  is  easy  to  add.) 

-  A  list  of  unique  ids  of  certificates  on  which  a  proof  depends  can  be  included  in 
the  procap  generated  from  it.  Before  admitting  a  procap,  the  file  system  backend 
can  compare  the  list  of  certificate  ids  in  it  to  a  list  of  revoked  certificates  provided 
by  administrators.  If  there  is  an  overlap,  the  procap  can  be  rejected.  Although 
this  method  would  enforce  revocation  perfectly,  it  would  also  slow  down  file  access 
because  an  additional  check  must  be  performed  on  each  procap. 

-  Alternatively,  the  list  of  revoked  certificates  can  be  provided  to  the  proof  verifier 
instead  of  the  file  system  backend.  The  verifier  can  then  refuse  to  accept  any  proof 
that  depends  on  revoked  certificates.  If  the  verifier  issues  a  procap,  it  can  be  short 
lived,  i.e.,  its  validity  can  be  restricted  to  a  short  duration  T  using  a  constraint  on 
ctime.  Although  the  effect  of  revocation  in  this  method  is  not  immediate  (it  can 
lag  by  a  time  T),  the  file  system  backend  does  not  get  involved,  so  its  performance 
is  not  affected. 
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5  PCFS  Backend 


Whereas  the  front  end  of  PCFS  is  used  to  generate  procaps  from  proofs  of  access,  the 
backend  grants  access  to  files  and  directories  using  the  procaps  to  check  access  rights. 
The  two  ends  are  linked  by  procaps  only;  indeed  the  backend  of  the  file  system  is  entirely 
agnostic  to  the  logic  used.  If  we  had  a  different  logic  for  writing  the  policy,  we  could 
use  the  same  backend,  so  long  as  the  logic’s  proof  verifier  generated  the  same  procaps. 
Since  the  backend  is  called  at  every  single  file  access,  it  needs  to  be  extremely  efficient. 
In  this  section,  we  discuss  its  design  and  implementation. 

Overall  architecture.  The  PCFS  backend  is  implemented  as  a  process  server,  which 
listens  to  upcalls  made  by  the  kernel  module  Fuse.  The  latter  happens  whenever  a 
process  makes  a  system  call  to  access  a  file  or  directory  within  the  mount  path  of  PCFS. 
Depending  on  the  operation  requested,  a  specific  handling  function  is  invoked.  There  is 
one  function  for  every  POSIX  file  system  operation  like  open,  read,  write,  stat,  unlink, 
rmdir,  mkdir,  etc.  This  handling  function  looks  up  and  checks  procaps  corresponding 
to  permissions  needed  to  perform  the  operation.  If  the  checks  succeed,  it  invokes  an 
identical  file  system  call,  but  on  a  different  mount  path,  which  is  actually  an  ext3  file 
system.  In  order  to  bypass  any  access  checks  during  the  call  to  the  ext3  file  system,  the 
process  server  runs  with  superuser  privileges.  To  prevent  users  from  directly  using  the 
ext3  file  system  to  access  data,  we  give  ownership  of  the  root  directory  on  the  ext3  file 
system  to  the  superuser,  and  turn  off  all  access  on  it.^ 

Organization  of  the  file  system.  For  the  purpose  of  illustration  let  us  assume  that 
PCFS  is  mounted  at  /pcf  s,  and  that  it  makes  calls  to  the  ext3  file  system  at  / src.  Then 
/pcfs  mirrors  the  file  system  structure  rooted  at  /src,  except  that  all  calls  within  the 
former  are  subject  to  procap  based  checks.  A  special  directory  /pcf  s/#conf  ig  contains 
configuration  data  for  the  file  system,  including  procaps  and  the  secret  key  used  to 
sign  them.  This  directory  is  protected  by  the  file  system  with  strict  rules  that  do  not 
use  procaps.  We  list  below  some  of  the  important  files  and  directories  in  this  special 
directory,  as  well  their  contents  and  protections. 

/pcf s/#conf ig/conf ig-f ile:  File  containing  configuration  options,  including 
the  user  ids  of  the  principals  admin  and  pcfssystem.  (Recall  from  Section  4  that 
pcfssystem  is  the  only  user  who  has  access  to  the  secret  key  needed  to  sign  procaps.) 
Anyone  can  read  this  file,  but  only  pcfssystem  can  change  this  file. 

/pcf  s/#conf  ig/shared-key:  Contains  the  shared  key  used  to  sign  procaps.  Only 
pcfssystem  may  read  or  write  this  file. 

/pcfs/#conf  ig/ca-pubkey  .pem:  Contains  the  public  key  of  the  certifying  author¬ 
ity  who  signs  associations  between  other  public  keys  and  users.  Anyone  may  read 
this  file,  but  only  pcfssystem  may  write  to  it. 

more  secure  method  to  prevent  access  via  the  underlying  file  system  is  to  keep  data  encrypted  on 
it,  and  to  decrypt  data  in  our  process  server.  We  have  not  implemented  this  design,  since  our  objective 
here  is  to  evaluate  the  performance  of  access  checks. 
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/pcf  s/#conf  ig/procaps/:  This  directory  contains  the  procaps.  Its  organization 
is  discussed  next,  pcfssystem  has  full  access  to  this  directory,  and  other  users  have 
access  to  specific  subdirectories  only. 

The  procap  giving  the  right  {k,f,r]),  subject  to  access-time  conditions  as  discussed 
before,  is  stored  in  the  file  /pcf s/#config/procaps/</c>/</> .perm. <r/>.  Here  <k>  is 
the  user  id  of  the  user  k,  </>  is  the  path  of  the  file  /  (relative  to  the  mount  point), 
and  <ri>  is  a  textual  representation  of  the  permission.  Thus  each  procap  is  stored  in  a 
separate  file,  and  further  for  each  right  {k,  /,  rj),  there  can  be  at  most  one  procap  that 
authorizes  the  right.  While  this  may  be  restrictive,  it  makes  look  up  extremely  easy  since 
the  exact  path  where  a  procap  is  to  be  found  can  be  determined  simply  by  knowing  the 
PCFS  mount  point  and  the  right  {k,f,7]).  To  prevent  denial  of  service  attacks  and  to 
protect  user  privacy,  the  PCFS  server  ensures  that  only  user  k  can  access  (read,  write, 
or  delete)  files  inside  /pcf  s/#conf  ig/procaps/</c>/. 

Since  pcfssystem  has  full  access  to  all  files  and  directories  within  /pcf  s/#conf  ig/, 
it  is  a  very  attractive  target  for  attack.  In  particular,  if  an  attacker  gains  control  of 
this  user  account,  it  can  change  the  secret  key  used  to  sign  and  verify  procaps,  and 
then  inject  fake  procaps  to  access  other  files.  To  prevent  this,  the  PCFS  process  server 
denies  pcfssystem  all  rights  in  other  directories  within  the  file  system.  Thus,  to  attack 
PCFS  through  this  mechanism,  the  attacker  must  break  into  at  least  one  more  account 
in  addition  to  pcfssystem. 

Procap  Cache.  Since  procaps  are  stored  in  files,  and  one  or  more  of  them  must 
be  read  for  every  file  system  operation,  it  is  helpful  to  cache  commonly  used  procaps 
in  memory  to  improve  performance.  To  this  end,  PCFS  uses  a  least  recently  used 
(LRU)  in-memory  cache,  whose  size  can  be  adjusted  at  mount  time.  The  cache  stores 
parsed  procaps,  whose  signatures  have  already  been  verified.  The  only  cost  involved  in 
using  a  cached  procap  is  checking  its  conditions  (lists  C  and  i  from  Section  4).  This  is 
extremely  fast  and  usually  takes  only  lO-lOO/zs.  As  a  result,  PCFS  obtains  extremely 
high  performance  when  the  number  of  files  in  use  is  small.  We  evaluate  the  effect  of  the 
cache  in  Section  6. 

Permissions.  PCFS  uses  five  distinct  permissions  on  any  file  or  directory:  read,  write, 
execute,  identity,  and  govern.  (In  contrast,  POSIX  mandates  only  the  first  three  permis¬ 
sions.)  Permissions  read  and  write  are  the  obvious  ones;  they  are  needed  to  read  and  to 
change  the  contents  of  a  file/directory  respectively.  As  usual,  execute  is  the  permission 
to  read  the  meta  data  of  a  file  or  directory.  Permission  identity  is  needed  to  delete  a  file 
or  directory,  or  to  rename  it.  This  permission  is  separated  from  others  because  in  many 
settings,  administrators  may  not  want  to  allow  users  to  delete  or  rename  shared  files, 
but  perform  other  operations  on  them  (and  their  parent  directories).  The  govern  permis¬ 
sion  is  needed  to  change  the  owner  of  a  file  and  to  change  extended  attributes  starting 
with  the  prefix  usen.^^tpcf  s.  Because  of  this  special  protection,  these  attributes  can  be 
used  by  administrators  to  give  classification  or  security  labels  to  files,  as  in  Example  1. 
Figure  3  lists  the  permissions  needed  to  perform  some  common  file  system  operations. 
During  a  file  system  call,  procaps  corresponding  to  the  relevant  entry  in  this  table  are 
looked  up  and  checked.  By  separating  the  identity  and  govern  permissions  from  write,  we 
allow  for  the  possibility  of  easily  administering  both  mandatory  and  discretionary  access 
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Operation 

Permissions  needed 

stat  /foo 

execute  on  /foo 

open  /foo  in  read  mode 

read  on  /foo 

open  /foo  in  write  mode 

write  on  /foo 

create  /bar /foo 

write  on  /bar 

delete  /bar/foo 

identity  on  /bar/foo 

rename  /bar  to  /foo 

identity  on  /bar,  write  on  /foo 

getxattr  on  /foo 

execute  on  /foo 

setxattr  on  /foo 

govern  on  /foo  if  attribute  starts  with 
user.#pcfs.,  write  otherwise 

chown  on  /foo 

govern  on  /foo 

Figure  3:  Permissions  needed  to  perform  some  operations 


control  in  PCFS.  This  is  difficult  with  POSIX  permissions,  where  the  owner  always  has 
all  permissions  on  a  file. 

Default  Permissions.  When  a  program  first  creates  a  file,  it  cannot  be  assumed 
that  any  policy  rules  apply  to  it,  since  that  (usually)  requires  creation  of  certificates  by 
administrators.  Yet,  many  programs  create  temporary  files,  to  which  they  must  have 
access  in  order  to  complete  their  tasks.  To  allow  such  programs  to  execute  correctly, 
when  a  new  file  or  directory  is  created,  PCFS  automatically  creates  and  stores  default 
procaps  that  give  the  creator  of  the  file  read,  write,  execute,  and  identity  permissions  for 
a  fixed  period  of  time  (this  period  can  be  adjusted  at  mount  time).  In  addition  the  user 
admin  is  given  execute  and  govern  rights  on  the  new  file.  After  this  period  elapses,  the 
default  procaps  expire  and  the  administrators  must  create  policy  rules  to  control  access 
to  the  file. 

6  Evaluation 

We  evaluate  PCFS  in  two  ways.  First,  we  report  the  results  of  performance  benchmarks 
on  the  backend  of  the  file  system.  Second,  we  comment  on  the  expressiveness  of  the 
framework  through  two  case  studies. 

6.1  Performance  of  the  Backend 

Since  we  are  primarily  interested  in  measuring  the  overhead  of  access  control  checks 
due  to  procaps,  our  baseline  for  comparing  performance  is  a  Fuse-based  file  system 
that  does  not  perform  the  corresponding  checks,  but  is  otherwise  running  a  process 
server  and  using  an  underlying  ext3  file  system,  just  as  PCFS  does.  We  call  this  file 
system  Fuse/Null.  For  macrobenchmarks  we  also  compare  with  an  ext3  file  system.  All 
measurements  reported  here  were  made  on  a  2.4GHz  Core  Duo  2  machine  with  3GB 
RAM  and  a  7200RPM  100GB  hard  disk  drive,  running  the  Linux  kernel  2.6.24-23. 

Read  and  write  throughput.  By  default,  PCFS  does  not  make  any  access  checks 
when  read  or  write  operations  are  performed  on  a  previously  opened  file.  Instead  access 
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checks  are  made  when  the  file  is  opened.  As  a  result  its  read  and  write  throughput 
is  very  close  to  that  of  Fuse/Null.  The  following  table  summarizes  the  read  and  write 
throughputs  of  PCFS  and  Fuse/Null  based  on  reading  and  writing  a  1GB  file  sequentially 
using  the  Bonnie++  test  suite  [1]. 


Operation 

PGFS  (MB/s) 

Fuse/Null  (MB/s) 

Read 

538.69 

567.47 

Write 

73.18 

76.05 

It  is  possible,  through  a  mount  time  option,  to  force  PCFS  to  check  procaps  that  au¬ 
thorize  read  and  write  access  during  read  and  write  operations  respectively.  As  long  as 
the  procaps  checked  are  cached  in  memory,  this  does  not  affect  performance  at  all  since 
the  time  taken  to  check  a  cached  procap  is  only  a  few  microseconds. 

File  stats.  Besides  read  and  write,  two  other  very  common  file  operations  are  open 
and  stat  (reading  a  file’s  meta  data).  In  terms  of  access  checks,  both  are  similar,  since 
usually  one  procap  must  be  checked  in  each  case.^  The  table  below  shows  the  speed  of  the 
stat  operation  in  PCFS  with  different  hit  rates  in  the  procap  cache.  All  measurements 
are  reported  in  number  of  operations  per  second,  as  well  as  time  taken  per  operation. 
The  title  n%  indicates  a  measurement  with  a  cache  hit  rate  of  n%.  For  comparison, 
performance  of  Fuse/Null  is  also  shown.  The  figures  are  based  on  choosing  a  random 
file  20,000  times  in  a  directory  containing  exactly  20,000  files,  and  stating  it.  To  get  a 
hit  rate  of  n%,  the  cache  size  is  set  to  n/100  x  20000,  and  the  cache  is  warmed  a  priori 
with  random  procaps.  It  is  easy  to  prove  that  for  an  LRU  cache  this  results  in  a  hit 
rate  of  exactly  n%  when  subsequent  files  (procaps)  are  also  chosen  at  random. 


Gache  hit  rate  — > 

0% 

50% 

90% 

95% 

98% 

100% 

Fuse/Null 

Stats  per  second 

5774 

7186 

8871 

9851 

11879 

23652 

36042 

Time  per  stat  (/ts) 

173.2 

139.2 

112.7 

101.5 

84.2 

42.2 

27.7 

As  can  be  seen  from  this  table,  the  procap  cache  is  extremely  helpful  in  attaining 
efficiency.  The  difference  of  the  times  in  the  last  two  columns  is  an  estimate  of  the  time 
it  takes  to  check  a  cached  procap  (i.e.,  the  time  needed  to  check  the  conditions  in  a 
procap).  In  this  case,  this  time  is  42.2  —  27.7  =  14.5^s.  This  estimate  is  rough,  and  the 
actual  time  varies  with  the  complexity  of  the  conditions  in  the  procap.  The  procaps  used 
here  are  default  ones.  In  other  experiments,  we  have  found  that  this  time  varies  from  10 
to  100/rs.  By  taking  the  difference  of  the  times  in  first  and  last  columns,  we  obtain  an 
estimate  of  the  time  required  to  read  a  procap,  check  its  signature,  parse  the  procap,  and 
check  its  conditions.  In  this  experiment,  this  time  is  173.2  —  27.7  =  145.5/rs.  Additional 
time  may  be  needed  to  seek  to  the  procap  on  disk,  which  is  not  counted  here.  This 
suggests  that,  in  general,  procap  checking  is  dominated  by  reading  and  parsing  times. 
The  signatures  we  use  for  procaps  are  message  authentication  codes  or  MAGs,  which 
can  be  verified  in  1  to  2/is. 

^Two  procaps  must  be  checked  when  a  file  is  opened  in  read  and  write  modes  simultaneously. 
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File  creation  and  deletion.  The  table  below  lists  the  number  of  create  and  delete 
operations  per  second  that  are  supported  by  PCFS  and  Fuse/Null.  These  are  measured 
by  creating  and  deleting  10,000  files  in  a  single  directory. 


Operation 

PCFS  (op/s) 

Fuse/Null  (op/s) 

Create 

1386 

4738 

Delete 

1989 

15429 

PCFS  is  approximately  3.5  times  slower  than  FUSE/Null  in  creating  files.  This  is 
because  PCFS  also  creates  six  default  procaps  for  every  file  created.  As  a  result,  it 
creates  seven  times  as  many  files  in  three  separate  directories.  Deletion  in  PCFS  is 
nearly  7.7  times  slower  than  that  in  Fuse/Null.  This  is  because  when  a  file  is  deleted 
in  PCFS,  one  procap  must  be  looked  up,  parsed,  and  checked,  and  all  procaps  related 
to  the  file  must  later  be  deleted.  This  is  done  to  avoid  accumulating  useless  procaps;  it 
can  be  turned  off  using  a  mount  time  option.  In  this  case,  each  file  deletion  corresponds 
to  seven  file  deletions  on  the  ext3  file  system  in  three  different  directories.  The  effect  of 
the  procap  cache  is  negligible  during  create  and  delete  operations. 

In  summary,  assuming  a  low  rate  of  cache  misses,  the  performance  of  PCFS  on  com¬ 
mon  file  operations  like  read,  write,  stat,  and  open  is  comparable  to  that  of  Fuse/Null. 
On  the  other  hand,  less  common  operations  like  create  and  delete  are  slower  because 
default  procaps  must  be  managed. 

Macrobenchmarks.  To  understand  the  performance  of  PCFS  in  practice,  we  also  ran 
two  simple  macrobenchmarks.  The  first  (called  OpenSSL  in  the  table  below),  untars 
the  OpenSSL  source  code,  compiles  it  and  deletes  it.  The  other  (called  Fuse  in  the  table 
below) ,  performs  similar  operations  for  the  source  of  the  fuse  kernel  module  five  times  in 
sequence.  As  can  be  seen,  the  performance  penalty  for  PCFS  as  compared  to  Fuse/Null 
is  approximately  10%  for  OpenSSL,  and  2.5%  for  Fuse.  The  difference  arises  because 
the  OpenSSL  benchmark  depends  more  on  file  creation  and  deletion  as  compared  to  the 
Fuse  benchmark. 


Benchmark 

PCFS  (s) 

Fuse/Null  (s) 

Ext3  (s) 

OpenSSL 

126 

114 

94 

Fuse  X  5 

79 

77 

70 

6.2  Case  Studies 

We  have  also  completed  two  case  studies  using  BL  and  PCFS.  In  each  case,  we  expressed 
the  policy  from  the  case  study  in  BL,  and  considered  whether  it  could  be  enforced  in 
PCFS. 

Classified  Information.  Our  first  case  study  formalizes  rules  for  control  and  dissem¬ 
ination  of  classified  information  among  intelligence  agencies  in  the  U.S.  (Examples  1 
and  2  are  based  on  this  case  study.)  The  enforcement  of  these  rules  was  also  the  origi¬ 
nal  motivation  for  building  PCFS.  We  obtained  information  on  these  rules  from  public 
government  documents,  and  through  an  industrial  collaborator.  This  information  was 
distilled  to  35  formulas  in  BL.  The  study  is  interesting  because  it  uses  almost  all  fea¬ 
tures  of  BL.  Extended  attributes  are  used  to  represent  the  classification  status  of  files 
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(classified  vs  unclassified),  and  their  classification  level  as  in  Example  1.  Attributes  of 
individuals  are  specified  in  certificates  issued  by  administrators,  many  of  which  expire  at 
fixed  points  of  time.  For  example,  some  background  checks  expire  every  5  years.  These 
expirations  are  represented  using  the  @  connective  in  BL.  Also,  one  of  the  rules  requires 
arithmetic  over  time  -  the  owner  of  an  unclassified  file  can  access  it  for  90  days  after  its 
creation.  (BL  supports  linear  arithmetic  over  time,  but  we  have  not  discussed  it  in  this 
paper.) 

Some  of  the  proofs  needed  for  access  in  this  study  are  quite  large;  they  contain  as 
many  as  1100  proof  steps,  and  depend  on  70  certificates.  It  takes  nearly  100ms  to  verify 
these  proofs.  This  strongly  supports  the  case  for  performing  proof  verification  ahead  of 
access  and  using  capabilities,  as  PCFS  does.  If  such  proof  verifications  were  performed 
during  file  access,  the  file  system  interface  would  be  limited  to  less  that  10  operations  a 
second. 

Course  administration.  In  our  second  case  study  we  formalize  the  rules  for  con¬ 
trolling  permissions  on  directories  for  storing  class  materials  and  assignments,  based  on 
current  workflows  at  our  university.  Although  these  rules  are  much  simpler  than  those 
in  the  previous  study,  we  had  to  add  support  for  a  new  kind  of  interpreted  predicate: 
member(/,  d),  which  means  that  file  /  is  contained  in  directory  d.  This  effort  gave  us 
an  idea  about  the  difficulty  involved  in  extending  PCFS  (and  BL)  with  new  interpreted 
predicates.  In  all,  it  took  us  less  than  10  minutes  of  programming  effort  to  add  support 
for  this  new  predicate.  (All  parsers  in  our  implementation  already  support  parsing  of 
unknown  predicates,  so  we  only  had  to  define  a  procedure  for  verifying  the  predicate.) 

7  Related  Work 

A  lot  of  prior  work  is  related  to  PCFS;  here  we  describe  only  the  most  closely  related 
work. 

Relation  to  PC  A.  Proof-carrying  authorization  (PCA),  the  general  architecture  on 
which  PCFS  builds,  has  been  implemented  in  several  other  systems  [8,  9,  25].  However, 
PCFS  differs  from  these  systems  in  several  ways.  The  most  significant  difference  is 
that  in  all  existing  PCA-based  systems,  the  proof  that  the  user  constructs  is  given 
directly  to  the  system  interface  at  the  time  of  access.  As  a  result,  the  proof  verifier  must 
be  called  every  time  an  aeeess  is  requested.  This  design  works  well  only  when  the  time 
taken  to  check  certificates  and  the  proof  (typically  several  milliseconds)  is  not  significant 
in  comparison  to  the  time  taken  to  perform  the  actual  operation.  This  has  been  the 
case  in  all  implementations  of  PCA  to  date.  In  contrast,  a  file  system  access  is  a  fast 
operation  that  takes  of  the  order  of  a  few  micro  or  milli  seconds  only,  and  checking 
several  certificates  and  a  proof  at  each  access  results  in  visible  delays  for  the  user.  We 
actually  confirmed  this  hypothesis  through  an  earlier  implementation  of  PCFS  that  used 
the  PCA  architecture  directly.  As  a  result  of  this  prior  experience,  in  the  present  design 
of  PCFS,  proofs  are  verified  in  advance  of  performing  operations,  and  capabilities  issued 
in  return  are  used  to  authorize  access. 

Second,  the  logic  used  in  in  PCFS  (discussed  in  Section  3)  contains  explicit  time. 
This  allows  accurate  representation  of  expiration  dates  of  policy  rules  in  logical  formulas 
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and  also  in  proofs.  In  contrast,  logics  used  so  far  in  PCA  systems  are  unaware  of  time, 
and  rule  expiration  is  enforced  using  an  extra-logical  mechanism.  Having  time  in  the 
logic  also  allows  more  expressive  rules,  e.g.,  those  that  use  arithmetic  over  time. 

Third,  in  all  existing  implementations  using  PCA,  the  user  is  authenticated  to  the 
system  interface  using  a  challenge  response  protocol  with  a  fresh  nonce.  This  nonce  must 
be  embedded  in  the  proof  used  to  authorize  access  because  the  interface  does  not  learn 
the  identity  of  the  user.  This  implies  that  the  proof  cannot  be  completed  in  advance 
of  the  access  (although  some  parts  of  it  that  are  independent  of  the  nonce  can  be). 
Owing  to  concerns  regarding  efficiency,  we  do  not  consider  this  style  of  authentication 
a  good  design  principle  for  PCA.  Instead,  we  believe  that  the  authentication  protocol 
used  should  tell  the  system  interface  the  identity  of  the  user.  In  distributed  settings  a 
password  or  public  key  can  be  used  for  authentication,  and  in  centralized  settings  like 
PCFS  the  system  interface  can  learn  the  user  id  of  the  calling  process  through  a  system 
call  like  getuidO.  This  form  of  authentication  allows  proofs  of  access  to  be  created 
and  checked  in  advance  of  access,  which  is  central  to  obtaining  efficiency  in  PCFS. 

Other  related  work.  Many  prior  file  systems  have  used  capabilities  to  authorize 
access  (e.g.,  [6,  20,  28,  31,  32]),  although  the  use  of  proofs  to  generate  capabilities  is 
novel  to  our  work.  Prior  work  by  Chaudhuri  considers  a  formal  analysis  of  correctness 
of  an  implementation  of  authorization  through  cryptographic  capabilities  in  the  face  of 
dynamic  policies  [13].  That  paper  also  considers  many  strategies  for  enforcing  time- 
dependent  and  state-dependent  policies,  but  the  mechanism  used  to  generate  policies  is 
treated  abstractly  (in  contrast,  in  Theorem  4.1,  we  prove  our  enforcement  correct  with 
respect  to  a  concrete  logic  and  proof  system) . 

Many  logics  and  logic-based  languages  have  been  proposed  in  the  past  for  represent¬ 
ing  access  control  policies  (e.g.,  [4,  5,  10,  14,  18,  21,  30]).  The  k  says  s  modality  in  BL 
is  most  closely  related  to  a  similar  modality  in  Binder  [14].  Our  treatment  of  explicit 
time  draws  on  work  by  DeYoung  et  al.  [16].  We  believe  that  the  combination  of  time 
and  interpreted  predicates  is  novel  to  BL.  The  implementation  of  the  proof  search  tool 
for  BL  builds  upon  work  on  uniform  proofs  for  logic  programming  [27],  and  draws  on 
ideas  from  the  language  Lolli  [22]. 

8  Conclusion 

PCFS  combines  strong  logical  foundations  for  access  policies  with  an  efficient  enforce¬ 
ment  based  on  proofs  and  cryptographic  capabilities.  Owing  to  a  very  expressive  logic 
for  policies,  and  conditions  in  capabilities,  PCFS  automatically  enforces  time-dependent 
policy  rules,  as  well  as  policies  that  depend  on  file  system  state.  A  significant  contribu¬ 
tion  of  our  work  is  Theorem  4.1  which  shows  that  enforcement  of  policies  using  procaps 
is  sound  with  respect  to  enforcement  with  proofs  directly  (as  in  PCA). 

A  number  of  interesting  avenues  remain  for  future  work  that  we  discuss  here  briefly. 
One  interesting  direction  is  to  apply  the  PCFS  architecture  to  build  a  networked  file 
system,  with  the  proof  verifier  and  storage  on  separate  nodes,  and  a  decentralized  store 
for  procaps.  Procaps  already  support  decentralization,  since  their  integrity  is  protected 
by  the  signature  contained  in  them.  Another  interesting  line  of  work  may  be  to  use 
capabilities  to  implement  access  control  on  devices  that  have  little  computational  power 
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(e.g.,  embedded  devices),  and  support  them  with  the  existing  front  end  from  PCFS  that 
runs  on  a  separate  machine.  A  third  subject  of  interest  is  to  consider  more  case  studies 
of  policies  used  in  practice  to  see  if  they  can  be  expressed  and  enforced  in  PCFS. 
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A  Description  of  the  Logic  BL 

This  appendix  describes  the  proof  system  of  the  logic  BL,  and  its  meta  theory.  The 
syntax  of  the  logic  was  presented  in  Section  3.  Proof  terms  M  are  summarized  below: 

M  ::=  X  \  pf_conjI  Mi  M2  ]  pf_conjEl  M  j  pf_conjE2  M  j  pf_disjll  M  j 
pf_disjI2  M  j  pf.disjE  M  ([x]Mi)  ([y]M2)  \  pf_topI  j  pf.botE  M  j 
pf_inipl  ([x] [ui] [u2]M)  j  pf_impE  Mi  M2  ui  U2  \  pf_forallI  {[v]M)  \ 
pf_forallE  t  M  \  pf_existsl  t  M  \  pf_existsE  Mi  ([x][x]M2)  ] 
pf_atl  M  j  pf_atE  Mi  ([x]M2)  ]  pf-saysl  M  j  pf.saysE  Mi  ([x]M2)  ] 
pf_sinjl  j  pf.sinjE  Mi  M2  ]  pf.cinji  j  pf_cinjE  Mi  M2 

Variables  x,v  in  square  brackets  [x],  [x]  are  binding  occurrences.  Bound  variables  may 
be  a-renamed  implicitly. 

Figures  4  and  5  list  the  rules  of  the  natural  deduction  system  for  BL.  All  rules  in 
Figure  4  are  similar  to  corresponding  rules  in  prior  work  by  DeYoung  [15,  Chapter  5], 
done  in  the  context  of  7?-logic  [16].  There  are  only  two  minor  differences:  (a)  Our  rules 
contain  the  view  a  and  the  state  E  both  of  which  remain  unchanged  in  all  rules  of 
Figure  4,  and  (b)  BL  contains  the  connective  T  (rule  TE),  which  r/-logic  does  not.  For 
descriptions  of  the  rules  in  Figure  4,  we  refer  the  reader  to  the  prior  work  by  DeYoung. 
Rules  in  Figure  5  are  peculiar  to  BL.  Rule  (hyp)  states  that  the  assumption  s  o 
entails  s  o  [ui,U2]  if  u'^  <  ui  and  U2  <  u'2,  i.e.,  the  interval  [ui,U2]  is  a  subset 
of  the  interval  [u'^,?/^].  This  makes  intuitive  sense:  if  a  formula  s  holds  throughout  an 
interval,  it  must  hold  on  every  subinterval  as  well.  The  proof  term  corresponding  to 
this  (trivial)  derivation  is  x,  where  x  is  also  the  name  for  the  assumption  s  o  [u^^jX^]. 
The  rule  (claims)  is  similar,  except  that  it  allows  us  to  conclude  s  o  [ui,U2\  from  the 
assumption  k'  claims  s  o  [tt)^,?/^].  In  this  case,  it  must  also  be  shown,  among  other 
things,  that  k'  is  stronger  than  the  principal  k  in  the  view  (premise  ^  \=  k'  Yk). 

(saysl)  is  the  only  rule  which  changes  the  view.  The  notation  Fj  in  this  rule  denotes 
the  subset  of  F  that  contains  exactly  the  claims  of  principals,  i.e.,  the  set  {{k'  claims 
s'  o  [^,^2])  £  F}.  The  rule  means  that  {k  says  s)  o  [ui,U2]  holds  in  any  view  a  if 
s  o  [ui,U2]  holds  in  the  view  k,ui,U2  using  only  claims  of  principals.  Assumptions  of 
the  form  s'  o  [u'^ ,  u'2\  are  eliminated  from  F  in  the  premise  because  they  may  have  been 
added  in  the  view  a,  but  may  not  hold  in  the  view  k,  U\,U2-  Its  dual  rule  (saysE)  states 
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Ml  ::  S;  E;  r  si  o  [tii ,  112]  M2  S;  'I';  E;  F  S2  o  [ui ,  U2] 


AI 


(pf  _conjI  Ml  M2)  ::  S;  'F;  E;  F  — >  si  A  *2  °  [ui,  U2] 

M  ::  S;  'F;  E;  F  si  A  52  o  [wi,  112]  M  ::  S;  'F;  E;  F  si  A  S2  o  [iti,  112] 


(pf  _conjEl  M)  ::  S;  E;  F  — >  si  o  [ui ,  U2] 

M  ::  S;  'F;  E;  F  si  o  [ui ,  U2] 

(pf  _disj  II  M)  ::  E;  'F;  E;  F  si  V  S2  o  [ui ,  U2] 


-AEl 


-AE2 


-Vll 


(pf  _conjE2  M)  ::  E;  'F;  E;  F  — >  S2  o  [ui ,  U2] 

M  ::  E;  E;  F  S2  o  [111, 112] 
(pf_disjI2  M)  ::  E;  E;  F  si  V  S2  o  [tii,  U2] 


-VI2 


M  ::  E;  'F;  E;  F  si  V  S2  o  [ui^U2] 

Ml  ::  E;  'F;  E;  F,  X  :  SI  o  [ui ,  U2]  s^  o  [u'l ,  U2]  M2  E;  'F;  E;  F,  i;  :  S2  o  [ui ,  U2]  s^  o  [u'l,  U2] 
(pf_disjE  M  {[x]Mi)  {[y]M2))  E;^;E;F  s'  o  [11^,112] 

M  E;^;E;F  ±  o  [111,1(2] 


VE 


-TI 


(pf  _topl)  ::  E;  'F;  E;  F  T  o  [ki  ,  112]  (pf  _botE  M)  ::  E;  E;  F  s  o  [k^  ,  112] 

M  ::  E,  Di dime,  1)2 dime;  'F,  111  <  vi,V2  <  112;  E;  F,  x  :  si  o  [di,  112]  ■S2  o  [ki ,  V2\ 

(pf_lmpl  ([a;][iii][i!2]M))  E;'F;E;F  si  D  S2  o  [111,112] 

Ml  ::  E;  'F;  E;  F  si  D  S2  o  [111 , 112] 

M2  E;  'F;  E;  F  si  o  [11^ ,  u^]  ^  [=  111  <  iil  <  u'^  IF  \=  u'2  ^  112  ^  ^2 


-±E 


Dl 


(pf  _iinpE  Ml  M2  u'l  u'2)  ::  E;  E;  F  S2  o  [11^^,  u'2] 

M  E,  u:(t;  'F;  E;  F  s  o  [111 , 112] 
(pf_forallI  ([i;]M))  E;  E;  F  Vii:cr.s  o  [111 , 112] 


DE 


VI 


M  ::  E;  'F;  E;  F  Vii:ct.s  o  [111 ,112]  E  h  t  :  u 


VE 


M  ::  E;^;E;F  ^  s[f/i;]  o  [111,112]  E  h  i  :  cr 


(pf  _f  orallE  M  t)  ::  E;  IF;  E;  F  — >  s[I/'i’]  o  [ui,  112]  (pf  _existsl  t  M)  ::  E;  'F;  E;  F  — >  3v:a.s  o  [ui ,  112] 

Ml  ::  E;  'F;  E;  F  3v:a.s  o  [ui ,  112]  M2  ::  E,D:(T;'F;E;F,a;  :  s  o  [111 , 112]  s'  o  [u'l ,  112] . 
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(pf_existsE  Ml  ([u][a;]M2))  ::  E;^;E;F  s'  o  [111,112] 

M  ::  E;  'F;  E;  F  s  o  [iii,  112] 

(pf  _atl  M)  ::  E;  'F;  E;  F  (s  @  [111, 112])  o  [11  j ,  112] 

Ml  ::  E;^;E;F  ^  (s  @  [111,112])  o  Ki,H2]  ^2  ::  E;  E;  F,  x  :  s  o  [111,112]  ^  s'  o  [ii'i',ii2] 
(pf  _atE  Ml  ([a;]M2))  ::  E;  -F;  E;  F  ^  s'  o  [11'/,  u'2] 


-3E 


@E 


Figure  4:  BL:  Natural  Deduction,  Part  1 


that  a  proof  of  k  says  so  [m,  U2]  can  be  used  to  justify  an  assumption  of  the  equivalent 
judgmental  form  k  claims  so  [ui,  U2]. 

The  rule  (interl)  is  used  to  establish  interpreted  predicates.  It  states  that  an  inter¬ 
preted  atomic  formula  i  is  provable  if  it  holds  in  the  abstract  logical  representation  of  the 
environment  E.  The  proof  term  sinji  has  no  specific  structure;  it  is  merely  a  marker 
which  means  that  a  procedure  must  be  invoked  to  check  i  in  the  prevailing  environment. 
Its  dual  rule  (interE)  states  that  any  proof  of  i  o  [ui,M2]  justifies  the  addition  of  i  to 
the  environment.  In  particular,  the  time  interval  [mi,U2]  associated  with  an  interpreted 
predicate  is  meaningless.  Rules  (consi)  and  (consE)  are  similar  but  they  are  used  to 
establish  and  eliminate  constraints  reified  as  formulas. 
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a  =  k,ui,,u, 


'I'  1=  <  Ul  \=  U2  ^  U2 

- hyp 

a:  ::  S;  ’Jf;  E';  r,  X  :  s  o  [u'l ,  U2]  — s  o  [ui ,  U2] 

'I'  1=  tij  <  Ul  \=  U2  ^  U2  \=  Ui  <  Ufy  'I'  1=  Ue  <  U2 

X  ::  T>\'^:E:T,x  :  k'  claims  s  o  \u\  .u'r,]  so  \u^  .uo] 


^\=k'  yk 


claims 


M  ::  S;'I';£;;r|  s  o  [ui,U2] 


-saysl 


(pf  _saysl  M)  ::  E;  F  — >  {k  says  s)  o  [ui ,  U2] 

Ml  ::  E;  E;  r  {k  says  s)  o  [ui ,  U2]  M2  ::  E;^;F?;r,a;  :  k  claims  s  o  [ui,  U2\  o 

(pf  _saysE  Mi  ([a;]M2))  ::  E;  'F;  _E;  F  s^  o  [ui ,  U2] 

_E  1=  i 

- interl 

(pf  _sinjl)  ::  E;  'F;  E;  F  z  o  [ui,  U2] 

Ml  ::  E;'F;F;;F  i  o  [ui,U2]  M2  ::  E;'F;E,z;F  s'  o 


(pf_sinjE  Ml  M2)  ::  E;^;E;F  s'  o 
'F  1=  c 

- - - consi 

(pf_cinjl)  ::  E;  E\  F  — >  c  o  [ui,  U2] 

Ml  ::  E;’F;£;;F  CO  [ui,U2\  M2  ::  E;^',c;£;;F  ^  s'  o  [ui,^] 
(pf  _cinjE  Ml  M2)  ::  E;  .E;  F  s'  o 


interE 


consE 


saysE 


Figure  5:  BL:  Natural  Deduction,  Part  2 


Explanation  of  views.  The  use  of  views  a  is  unique  to  BL,  at  least  in  the  context 
of  authorization  logics,  and  we  would  like  to  explain  it  further.  In  general,  a  view 
a  =  k,Ub,Ue  can  be  thought  of  as  consisting  of  two  components:  the  principal  k  and 
the  interval  [ub,Ue\.  Since  a  view  changes  only  in  the  rule  (saysl),  the  view  k,Ub,Ue  on 
any  sequent  in  a  proof  is  determined  by  the  most  recently  encountered  goal  judgment 
{k  says  s)  o  [ub,Ue\-  The  importance  of  the  view  is  that  it  prevents  the  use  of  any 
assumptions  of  the  form  k'  claims  s'  o  [?/(,,  Wg]  unless  either  (a)  the  view  changes  due  to 
another  (saysl)  rule,  or  (b)  k'  is  stronger  than  k  and  rtg]  is  a  superset  of  the  interval 
[ub-,Ue\.  These  are  forced  by  the  premises  of  the  rule  (claims). 

Restriction  (b)  is  important  in  practice.  Suppose  we  try  to  establish  the  goal 
(admin  says  may(Alice, /secret. txt,  read))  o  [2009,2011]  to  allow  Alice  to  read  file  /secret. txt 
from  2009  to  2011.  The  use  of  views  ensures  that  (unless  a  (saysl)  is  encountered  in  a 
subgoal),  this  proof  will  only  depend  on  credentials  and  policies  that  are  (1)  created  by 
principals  stronger  than  admin,  and  (2)  valid  on  intervals  that  include  [2009,2011].  If 
we  omit  principals  from  views,  we  might  violate  (1),  allowing  principals  without  proper 
authority  to  influence  an  authorization.  If  we  omit  intervals  from  views,  we  run  the  risk 
of  allowing  expired  credentials  or  those  that  are  applicable  in  the  future  to  affect  an 
authorization.  Neither  of  these  is  desirable.  On  a  more  formal  note,  we  expect  that  the 
use  of  views  in  BL  will  lead  to  strong  non-interference  theorems,  like  those  established 
for  an  earlier  logic  without  explicit  time  [18],  allowing  us  to  formalize  these  intuitions. 
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A.l  Meta-Theory 

We  prove  some  interesting  meta-theoretic  properties  of  BL,  including  those  mentioned 
in  Section  3.  In  order  to  prove  these  properties  we  make  the  following  assumptions 
about  decision  procedures  for  constraints  and  interpreted  predicates.  In  particular,  we 
allow  free  parameters  (constants)  in  the  judgments  'k  |=  c  and  E  |=  i,  and  assume  that 
the  decision  procedures  treat  these  parameters  universally,  i.e,  truth  of  judgments  is 
closed  under  substitution  of  these  parameters  by  ground  terms.  This  is  formalized  by 
the  assumptions  (Substitution-cons)  and  (Substitution-state)  below. 

1.  (Hypothesis)  'k,c  |=  c. 

2.  (Weakening-cons)  'k  ^  c  implies  ^,c'  ^  c. 

3.  (Cut-cons)  'k  ^  c  and  'k,  c  ^  c'  imply  'k  \=  d . 

4.  (Substitution-cons)  'k  ^  c  implies  'k[t/u]  \=  c[t/v\. 

5.  (Refl-time)  ^  \=  u  <u. 

6.  (Trans-time)  \=  u  <u'  and  ^  \=  u'  <  u"  imply  'k  ^  rt  <  u" . 

7.  (Refl-prin)  ^  \=  k  d  k. 

8.  (Trans-prin)  'k  |=  A:  ^  A:'  and  ^  \=  k'  ^  k"  imply  ^  \=  k  y  k" . 

9.  (Weakening-state)  E  \=  i  implies  E,E'  \=  i 

10.  (Cut-state)  E  \=  i  and  E,i\=  i'  imply  E  \=  i! . 

11.  (Substitution-state)  E  \=  i  implies  E[t/v\  ^  i[t/v\. 

Definition  A.l.  Let  a  =  k,Ub,Ue  and  a'  =  A;', be  two  views.  We  say  that  a  is 
stronger  than  a'  under  constraints  di,  written  'k  |=  a  >  a'  if  the  following  hold: 

1.  \=kyk' 

2.  ^  \=Ub<  u[ 

3.  'k  ^  Mg  <  tie 

Lemma  A.l  (View  Subsumption).  Let  M  ::  S;'k;£';r  s  o  [mi,M2]  and  suppose 

\=  a  >  a' .  Then  M  ::  S;'k;iii;r  dE,  g  o  [mi,M2]  by  a  derivation  of  equal  or  smaller 
depth.^ 

Proof.  By  induction  on  the  given  derivation  oi  M  ::  s  o  [mi,M2],  case 

analyzing  the  last  rule. 

Ml  ::  S;4';R;r Si  o  [mi,m2]  M2  ::  S;  T;  R;  T S2  o  [mi,  M2] 

Case.  - — - - - — — — — — - — - - — - - - - —  Al 

(pf  _conj  I  Ml  M2)  ::  S;  T;  R;  r  — >  si  A  S2  o  [mi,  M2] 

We  have: 

"^The  depth  of  a  derivation  is  defined  as  the  maximum  number  of  rules  of  Figures  4  and  5  on  the 
unique  path  from  the  final  sequent  to  any  leaf. 
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(i.h.  on  1st  premise) 
(i.h.  on  2nd  premise) 
(Rule  Al  on  1  and  2) 


1.  Ml  ::  si  o  [tti,n2] 

2.  M2  ::  ^$20  [rti,U2] 

3.  (pf  _conjI  Ml  M2)  ::  S;  'I';  F  si  A  S2  o  ['^1,^2] 


Case.  Rules  (AE1)-(@E)  from  Figure  4  are  treated  as  in  the  case  above.  For  each 
of  these,  we  apply  the  induction  hypothesis  to  any  premise  that  contains  a,  and  then 
reapply  the  rule. 

'I'  1=  <  Iti  4'  ^  M2  <  U2 


Case 


hyp 


a;  ::  S;  4';  R;  r,  X  :  s  o  [u(,  s  o  [mi,  M2] 

1.  ^  \=  u'l  <  ui  and  'h  ^  U2  <  u'2 

2.  X  ::  S;  'h;  E;  r,  X  :  s  o  [n'l,  7X2]  s  o  [ui,  M2] 


(premises) 
(Rule  (hyp)) 


Oi  — 

<  Ui  \=  U2  <  u'2  4'  (=  <  Mf,  \=  Ue  <  u'2  4/  1=  /c'  A  fc 

Case.  - - - claims 

X  ::  E;  4';  E;  F,  x  :  k'  claims  s  o  [wi,  m^]  —^so  [ui,  U2] 

Let  a'  =  k",u'/,u''  and  \=  a  >  a' .  We  have: 


1.  ^  \=Ub  <  u'l 

2.  \=  <  Ub 

3.  4'  ^  Ml  <  u'l 

4.  4'  1=  m"  <  Me 

5.  4'  ]=  Me  <  u'2 

6.  4'  ^  m"  <  u'2 

7.  ^  ^  A:  A  A:" 

8.  4^  ^  A;'  A  A: 

9.  ^  ^  A;'  A  k" 

10.  'h  ^  Ml  <  Ml 

11.  'L  ^  M2  <  M2 

12.  X  ::  S;  4';  E;  F,  x  :  k'  claims  s  o  [m(^,  M2] 


(defn  of  4^  ^  a  A  a') 
(3rd  premise) 
(Assumption  (Trans-time)  on  1  and  2) 
(defn  of  4'  ^  a  A  a') 
(4th  premise) 
(Assumption  (Trans-time)  on  4  and  5) 
(defn  of  4'  ^  a  A  a') 
(5th  premise) 
(Assumption  (Trans-prin)  on  7  and  8) 

(1st  premise) 
(2nd  premise) 

S  O  [mi,M2] 


(Rule  (claims)  on  10,11,3,6,9) 


Case. 


M  ::  S;T;E;r|  s  o  [m,  m^] 

(pf  _saysl  M)  ::  S;  4';  E;  F  [k  says  s)  o  [ui,  M2] 


saysl 


1.  M  ::  S;4';E;F 


k,Ul,U2  r 

- >  S  O  [Mi,M2 


(premise) 
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2.  (pf_saysl  M)  :: 


{k  says  s)  o  [ui,U2] 


(Rule  (saysl)) 


Case. 


Ml  ::  S;  'I';  S;  F  ^  {k  says  s)  o  [ui,U2] 

M2  S;  'I';  i?;  r, X  :  fc  claims  s  o  [ui,  U2]  s'  o  [m(, 


Case 


(pf.saysE  Mi  ([x]M2))  ::  — >  s'  o  [u'l^u'^ 

1.  Ml  ::  S; ill;  r  {k  says  s)  o  [ui,  it2] 

2.  M2  v.  E]T ,x  :  k  claims  s  o  [iti, it2]  o  [u'^,  n2] 

3.  (pf_saysE  Mi  ([a;]M2))  ::  S;'I';ill;r  s'  o  [u'i,u'^  (Rule  (saysE)  on  1  and  2) 
E  h  i 


(i.h.  on  1st  premise) 
(i.h.  on  2nd  premise) 


(pf  _sinjl)  ::  S; E;  r  i  o  [ui,U2] 


-interl 


1.  E^i 

2.  (pf  _sinjl)  ::  E; E;  r z  o  [ui,  U2] 


(premise) 
(Rule  (interl)  on  1) 


Case. 


Ml  ^io  [ui,U2\  M2  ::  E;^;E,i;T  ^  s'  o  [u'l,^^], 

iirF  A/fi  A/foi  ■■  Y!’ Vl/‘  -IE  o  \ii'  iiL\ 


1.  Ml  ::  E;  d';  E;  r  i  o  [^1,^2] 

2.  M2  ::  E;^;E,i;r  ^  s' o  [u'i,u'2] 

3.  (pf  _sinjE  Ml  M2)  ::  E;  d';  E;  E  s'  o  [n'^,  n'2] 


(i.h.  on  1st  premise) 
(i.h.  on  2nd  premise) 
(Rule  (interE)  on  1  and  2) 


Case.  Rule  (consi):  similar  to  (sinji) 

Case.  Rule  (consE):  similar  to  (sinjE) 

□ 

Lemma  A. 2  (Constraint  substitution).  Suppose  'h  ^  cq  and  M  ::  E;'I',co;E;r  s  o 
[iii,ii2]-  Then,  M  ::  E; 'h;  E;  F  s  o  [m,  U2]  by  a  derivation  of  shorter  or  equal  depth. 

Proof.  By  induction  on  the  given  derivation  of  M  ::  E;'h,co;E;r  s  o  [ui,U2],  and 

case  analysis  of  its  last  rule.  The  interesting  cases  are  those  rules  where  'h  |=  •  is  used 

in  one  of  the  premises.  In  such  cases,  we  appeal  to  the  assumption  (Cut-cons).  In  the 

remaining  rules,  we  just  apply  the  induction  hypothesis  to  the  premises,  and  reapply 

the  rule  to  the  modified  premises.  Eor  illustration,  we  show  one  example  of  the  latter 

(rule  (AI)),  and  then  turn  to  the  more  interesting  cases. 

Ml  ::  S;T,  Co;  E;r Si  o  [111,112]  M2  ::  S;  T,  cq;  E;  F S2  o  [ui,  112] 

Case.  - - - Al 

(pf.conji  Ml  M2)  ::  S;T,co;E;F  — ^  si  A  S2  o  [111,112] 


1.  Ml  ::  E;'h;E;r  si  o  [ui,U2] 

2.  M2  ::  E;  'h;  E;  r  ^  S2  o  [ui,  U2] 
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(i.h.  on  1st  premise) 
(i.h.  on  2nd  premise) 


3.  (pf  _coiijI  Ml  M2)  ::  S;  'I';  E';  r  si  A  S2  o  ['^1,^2] 


(Rule  (AI)  on  1  and  2) 


Case, 


Ml  ::  T,;'i>,co;E]T  si  D  S2  o 

M2  ::  S; cq;  E;  F  si  o  [u(,  16^  cq  |=  ui  <  <  u”  cq  ^  U2  ^  U2  <  U2 

(pf  _impE  Ml  M2  u'l  u'2)  S; cq;  E;  F  s2  o  [m",  U2] 


DE 


1.  Ml  ::  S;'I';E;r  — >  si  D  S2  o  [ui,U2] 

2.  M2  ::  S;  'I';  E;  r  si  o  [u'l,  U2] 

3.  d'  ^  Co 

4.  'I'  ^  Ml  <  m'i  <  Ml 

5.  'I'  ^  U2  <  U2  <  M2 

6.  (pf_impE  Ml  M2  u'l  u'2)  S;'I';E;r  ^  S2  o  [u'l^u'^] 

4',  Co  \=  u'l  <  ui  4',  Co  h  ■'^2  <  u'2 


(i.h.  on  1st  premise) 
(i.h.  on  2nd  premise) 
(Assumption) 
((Cut-cons)  on  3  and  3rd  premise) 
((Cut-cons)  on  3  and  4th  premise) 
(Rule  (dE)  on  1,2, 4, 5) 


Case. 


X  ::  S;  4^,  cq;  E;  F,  x  :  so  [u(,  s  o  [mi,  M2] 


hyp 


1.  'h  ^  Co 

2.  ^  \=  u'l  <  Ml 

3.  d'  ^  M2  <  M2 

4.  X  ::  S;  'I';  E;  r,  X  :  s  o  [m'i,  u'2]  ^  s  o  [mi,  M2] 


(Assumption) 
((Cut-cons)  on  1  and  1st  premise) 
((Cut-cons)  on  1  and  2nd  premise) 
(Rule  (hyp)  on  2  and  3) 


Case. 


a=  k,  Ub,  Me  4',  Co  1=  u'l  <  Ml 

4^,  Co  ^  M2  <  u'2  4^,  Co  ^  u'l  <  Ub  4^,  Co  1=  Me  <  u'2  ^,Co  \=  k'  y  k 


X  ::  S;  4^,  co;  E;  F,  x  :  k'  claims  s  o  [m(,  m^]  — >  s  o  [mi,  M2] 


claims 


1.  'h  ^  Co 

2.  \=  u'l  <  Ml 

3.  'h  ^  M2  <  u'2 

4.  'h  ^  m'i  <  Ub 

5.  d'  ^  Me  <  u'2 

6.  \=  k'  '^k 


(Assumption) 
((Cut-cons)  on  1  and  1st  premise) 
((Cut-cons)  on  1  and  2nd  premise) 
((Cut-cons)  on  1  and  3rd  premise) 
((Cut-cons)  on  1  and  4th  premise) 
((Cut-cons)  on  1  and  5th  premise) 


7.  X  ::  S;  'h;  E;  E,  x  :  k'  claims  s  o  [m'i,  M2]  — >  s  o  [mi,  M2]  (Rule  (claims)  on  2-6) 


Case. 


4',co  h  c 


(pf  _ciiijl)  ::  S;  4/,  cq;  E;  F  — ^  c  o  [mi,  M2] 

1.  'h  ^  Co 

2.  4'  ^  c 


-consi 


(Assumption) 
((Cut-cons)  on  1  and  1st  premise) 
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3.  (pf  _ciiijl)  ::  S; 'I';  r c  o  [til,  tt2]  (Rule  (consi)  on  2) 

□ 

Theorem  A. 3  (Subsumption;  Theorem  3.2).  Suppose  the  following  hold: 

1.  M  ::  S;  'h;  S;  r  ^  s  o  [tii,  ti2] 

2.  \=  Ui  <  Un  and  'h  \=  Um  <  U2 
Then,  M  ::  S;  'h;  iii;  F  ^  s  o  [un,  Um] 

Proof.  By  induction  on  the  depth  of  the  given  derivation  of  M  ::  s  o 

[mi,U2])  and  case  analysis  of  its  last  rule.  Some  representative  cases  are  shown  below. 


Case. 


Ml  ::  S; R;  r  — ^  Si  o  [ui,  ti2]  M2  ::  S; F  — ^  S2  o  [ui,U2] 


(pf  _conj  I  Ml  M2)  ::  S; Fi;  r  — >  si  A  S2  o  [ui,U2] 

1.  Ml  ::  S;^';F;;F  si  o  [un,Um] 

2.  M2  ::  ^  S2  o  [un,Um] 

3.  (pf.conji  Ml  M2)  ::  si  A  S2  o  [un,Um\ 

M  ::  S;  ^';F;;r Si  A  S2  o  [111,112] 

Case.  - - - — - - -71-  --  - -  -AEl 

(pf  _coiijEl  M)  ::  S; R;  F  — >  si  o  [111, 112] 

1.  M  ::  S;  'F;  S;  F  si  A  S2  o  [tin,  Um] 

2.  (pf  _conjEl  M)  ::  S;  'F;  Fi;  F  si  o  [tin,  Um] 


AI 


(i.h.  on  1st  premise) 
(i.h.  on  2nd  premise) 
(Rule  (AI)  on  1  and  2) 


Case. 


-TI 


(pf  _topl)  ::  S;  'F;  R;  r  — ^  T  o  [111, 112] 

1.  (pf  _topl)  ::  S;  Fi;  F  T  o  [tin,  Um] 
M  ±0  [111,112] 


(i.h.  on  premise) 
(Rule  (AEI)  on  1) 


(Rule  (TI)) 


Case. 


TE 


(pf  _botE  M)  ::  E;  'F;  E;  r  — >  s  o  [ii(,  uf] 

1.  (pf  _botE  M)  ::  S;  'F;  Fi;  F  s  o  [tin,  Um] 


(Rule  (TE)  on  premise) 


M  ::  E, uptime, i;2:time;'F, 111  <  111,112  <  U2;E;T,x  :  Si  o  [111,112]  -T  S2  o  [111,112]  ^ 

Case.  — — - - — - - — - — — - — - - - — - —  Dl 

(pf_impl  ([x][iii][i>2]M))  ::  E;^';F;;r  — 1  si  D  S2  o  [111,112] 

1.  'F  ^  til  <  tin  (Assumption) 


2.  tF ,  tin  T  til  1=  til  T  tin 

3.  ^,Un  <  Vi  \=  Un  <  Vi 

4.  4^,  tin  <  t'l  1=  ttl  <  1^1 


((Weakening-cons)  on  1) 
(Refl-time) 
((Trans-time)  on  2,3) 


5.  M  ::  S,  tiihime,  U2:time;  'F,  tti  <  ui,  U2  <  112;  E;  F,  x  :  si  o  [vi,V2]  -^52°  [^1,^2] 
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(premise) 

6.  M  ::  S,  virtime,  z;2:time;  Un  <  vi,V2  <  U2',  E;T ,x  :  si  o  [r;!, '^2]  S2  o  [^1,^2] 

(Lemma  A. 2  on  4,5) 

7.  '^,V2  <  Um  \=  V2  <  U2  (Similar  to  4) 

8.  M  ::  S, uirtime,  7;2:time;  4', <  vi,V2  <  Um',E;T,x  :  si  o  [vi,V2]  ^82°  [vi,V2] 

(Lemma  A. 2  on  7,6) 

9.  (pf.impl  ([x][t>i][t'2]M))  ::  S;'I';£';r  si  D  S2  o  [un,Um]  (Rule  (dI)  on  8) 

Ml  ::  S;  4';  A;  F  4L  D  53  o  [mi,  M2] 

^  M2  ::  S;  4';  A;  r  4L  o  [u(,  4^  |=  Mi  <  <  u'l  ^  \=  U2  <  u'2  <  U2  ^ 

(pf_impE  Ml  M2  u'l  u'2)  ::  S;  4';  A;r  4L  53  o  [mi,M3] 

1.4'^  u'{  <  Un 
2.  4'  ^  Ml  <  u'l  <  Un 


3.  4^  1=  Um  <  u'2 

4.  4'  1=  Mm  <  u'2  <  M2 


(Assumption) 
((Trans-time)  on  1  and  premise  3) 
(Assumption) 
((Trans-time)  on  3  and  premise  4) 


5.  (pf.impE  Ml  M2  u'l  u'2)  ::  S;4';£';r  -^52°  [un,Um] 

(Rule  (dE)  on  1st, 2nd  premise  and  2,4) 

M  ::  E;  4';  A;  r  s  o  [mi,  U2] 


Case. 


Case 


(pf  _atl  M)  ::  E;  4';  A;  r  — >  (s  @  [ui,  U2])  o  [mii  m^ 

1.  (pf_atl  M)  ::  S;4';  A;r  (s  @  [mi,M2])  o  [un,Um\  (Rule  (@I)  on  premise) 

Ml  ::  E;  4^;  A;  r  4L  (s  @  [ui,  M2])  o  [m(,  m^  M2  ::  E;  4';  A;  F,  a;  :  so  [mi,  M2]  s'  o  [u'l,  u'l] 
(pf_atE  Ml  ([x]M2))  ::  E;4';  A;F  s'  o  [u'l,  u'l] 

1.  M2  ::  S;  4^;  A;  T,  X  :  s  o  [mi,M2]  s'  o  [M„,Mm]  (i-h-  on  2nd  premise) 

2.  (pf_atE  Ml  ([x]M2))  ::  S;4';A;r  ^  s'  o  [Mn,Mm] 

(Rule  (@E)  on  1st  premise  and  1) 

4/hM'i  <  Ml  4^  (=  M2  <  M3 


@E 


Case. 


X  ::  E;  4^;  A;  F,  X  :  s  o  [m'i,  m^  s  o  [mi,  M2] 

1.  4'  ^  Ml  <  Mn 

2.  4^  ^  m'i  <  Un 


hyp 


3.  4^  ^  Um  'E  U2 


33 


(Assumption) 
((Trans-time)  on  1st  premise  and  1) 
(Assumption) 


4.  'I'  ^  Um  ^  U2 


((Trans-time)  on  2nd  premise  and  3) 


5.  X  ::  S;  4';  iii;  r,  X  :  s  o  [n'^,  U2]  ^  s  o  [un,  Um] 


(Rule  (hyp)  on  2,4) 


Case. 


(y.  — 

VI/  <  Ui  4/  ^  M2  <  M2  4/  ^  m(  <  Mf,  4/  (=  Me  <  M2  "^1  [=  k'  ^  k 


X  ::  E;  4/;  R;  F,  x  :  fc'  claims  s  o  [m(,  m^]  — /■  s  o  [mi,  M2] 


claims 


1.  ^  \=Ul<Un 

2.  vh  ^  u'l  <  Un 

3.  4/  ^  Um  ^  U2 

4.  4/  ^  Um  ^  U2 


(Assumption) 
((Trans-time)  on  1st  premise  and  1) 
(Assumption) 
((Trans-time)  on  2nd  premise  and  3) 


5.  X  ::  S;  vh;  E;T,x  :  k'  claims  s  o  [m)^,  M2]  ^  s  o  [m^,  m^] 

(Rule  (claims)  on  2,4  and  3rd-5th  premises) 

k,U\  ,U2 


Case. 


M  ::  S;4';  A;r| 


s  o  [mi,M2] 


(pf  _saysl  M)  ::  S;  vl/;  U;  F  — >  (fc  says  s)  o  [mi,  M2] 

1.  'if  \=  k  y  k 

2.  if  \=  Ui  <Un 

3.  4/  ]=  Um  ^  U2 

4.  4/  ^  (A:,Mi,M2)  >  {k,Un,Um) 

5.  M  ::  S;  E;  T]  s  o  [mi,  M2] 


saysl 


6.  M  ::  S;^^;S;r| 


k.Un  I'^n 


>50  Ura\ 
a 


7.  (pf  _saysl  M)  ::  S;  4/;  iii;  T  — >  {k  says  s)  o  [m^,  Um\ 


(Refl-prin) 
(Assumption) 
(Assumption) 
(Definition  on  1-3) 

(Lemma  A.l  on  4  and  premise) 

(i.h.  on  5) 
(Rule  (saysl)  on  6) 


Case 


Ml  ::  S;  4/;  A;  F  4L  {k  says  s)  o  [mi,  M2] 

M2  ::  S;vl/;  A;F,x  :  k  claims  s  o  [mi,M2]  s'  o  [m'^jM^ 

-y— — saysE 


(i.h.  on  2nd  premise) 


(pf.saysE  Mi  ([x]M2))  ::  S;4/;A;F  s'  o  [m^jM^ 

1.  M2  ::  E;  if;  E;r,  X  :  k  claims  s  o  [mi,  M2]  ^  s'  o  [un,  Um] 

2.  (pf  _saysE  Mi  ([x]M2))  ::  S;  4^;  A;  T  s'  o  [m„,  Um] 

(Rule  (saysE)  on  1st  premise  and  1) 

E  h  i 


Case. 


(pf  _sinjl)  ::  E;  4/;  A;  F  — >  i  o  [mi,  M2] 

1.  (pf_sinjl)  ::E;ii;E;T  ^  i  o  [un,Um] 


-interl 


(Rule  (interl)  on  premise) 
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Ml  : :  S; r  i  o  \ui,U2\  M2  : :  S; i5,  i;  F  s'  o  [u', ,  u'^  . 

^S0,  III  I  I  __  -  -  -  -  -  - -  I. 

(pf  _sinjE  Ml  M2)  S; _B;  F  ^  s'  o  m^] 

1.  M2  ::  T,;'i/;E,i;T  ^  s'  o  [un,Um]  (i.h.  on  2nd  premise) 

2.  (pf.sinjE  Ml  M2)  ::  S;'I';£';r  ^  s'  o  [un,Um] 

(Rule  (interE)  on  1st  premise  and  1) 

□ 


Substitution.  M[M' /x]  denotes  the  capture  avoiding  substitution  of  proof  term  M' 
for  proof  variable  x  in  proof  term  M.  The  substitution  is  defined  by  induction  on  M. 
Since  it  follows  a  standard  template,  we  show  below  only  some  selected  clauses  of  the 
definition,  x  ^  M  means  that  x  does  not  occur  free  in  M. 

x[M'/x]  =  M' 

y[M'/x]  =  y  {x^y) 

(pf_conjEl  M)[M' /x]  =  pf_conjEl  {M[M' /x\) 

(pf.impi  ([y][ui][u2]M))[M7x]  =  pf.impl  ([2/][ui][u2]M[M7x])  (y  /  x  and  y  0  M) 

Theorem  A. 4  (Substitution;  Theorem  3.1).  The  following  hold: 

1.  M'  ::  S;  'h;  E;  T  ^  s  o  [ui,  U2]  and  M  ::  S;  'I';  E;  T,  x  :  s  o  [ui,  U2]  s'  o  [u'i,u'f\ 
imply  that  M[M' /x]  ::  S; E;  T  ^  s'  o  [u'^,  u'2] 

2.  M'  ::  S;  'h;  E]  r|  s  o  [^1,^2]  and  M  ::  S;  'h;  E;  T,  x  :  A:  claims  s  o  [tti,  tt2] 

s'  o  [u'l,  u'2]  imply  that  M[M'/x]  ::  S;  'h;  E;  T  s'  o  [u'l,  u'2] 

Proof.  By  simultaneous  induction  on  given  derivations  containing  M,  and  case  analysis 
of  the  last  rule  in  the  derivations.  We  show  some  interesting  cases  for  both  statements 
above.  The  other  cases  are  straightforward:  the  induction  hypothesis  is  applied  to  the 
premises  and  the  rule  is  applied  again. 


Proof  of  (1) 


Case. 


'I'  1=  ^1  ^  '*^1  \=  u'2  <U2 

X  ::  S;  T;  hi;  F,  X  :  so  [tti,  U2]  s  o  [u'i,u'f\ 


hyp 


1.  M'  ::  S;^;E;r  ^  so  [ui,U2] 

2.  4'  7  ^  xl'i  and  'h  7  ^2  —  ^2 

3.  M'  ::  S;^;E;r  ^  so  [u'l^u'f) 

4.  M'  =  x[M'/x] 


(Assumption) 
(Premises) 
(Lemma  A. 3  on  2  and  1) 
(Definition) 


Case. 


T  7  Ui  <  u'l  4'  7  '*^2  —  "*^2 


2/  ::  S;4';L;;F,x  :  s  o  [ui,U2],y  ■  s'  o  [u'/,m'2]  s'  o  [m'i,  «2j 


:hyp 
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1.  y  ::  S;  E;T,y:  s'  o  [u'{,  u'^]  s'  o  [u'^^u'^] 


2.  y[M' /x]  =  y 


(Rule  (hyp)  on  premises) 
(Definition) 


a  =  k,  Ub,  Ue 


'I'  1=  <  u'(  'i'  \=  u'2  ^  u'2  \=  u'l  <  Ub  \=  Ue  <  u'2  \=  k'  k 

Case.  - - - claims 

y  ::  S; ill;  r,  a;  :  s  o  [ui,  U2],  2/  :  k'  claims  r  o  [t6(,  — >  r  o  [u'(,  u'2] 

1.  y  ::  S;  'h;  E]T,y  :  k'  claims  r  o  [^1,^2]  ^  r  o  [u'{,  u'^  (Rule  (claims)  on  premises) 

2.  y[M' /x]  =  y  (Definition) 

M  ::  {T,x:  so  [^1,^2])!  r  o 

Case.  - - - says! 

(pf _saysl  M)  ::  E;  F, x  :  5  o  [ui, ^2]  — ^  {k  says  r)  o  [u'i^U2] 


1.  (r,x  :  s  o  [ui,ii2])|  =  r| 

2.  M  ::  S;  .E;  T\  r  o  ^ 


3.  (pf  _saysl  M)  ::  S;  'h;  ill;  D  (A:  says  r)  o  [u'^,  U2] 

4.  (pf_saysl  M)[M'/x]  =  (pf.saysl  M) 

Ml  ::  S;  4';  E;  r,  X  :  s  o  [wi,  M2]  (fc  says  r)  o  [mi, 


(Definition) 

(Premise  and  1) 
(Rule  (saysl)  on  2) 
(x  0  M  from  2) 


M2  ::  S;  4';  E;  r,  X  :  s  o  [ui,  M2],  y  :  A:  claims  r  o  [m(,  m^  r'  o  [u'{,  u'2] 

Case.  - - - saysE 

(pf_saysE  Mi  ([y]M2))  ::  S;  4';  E;  E,  x  :  s  o  [mi,M2]  — ^  r'  o  [mi,M2] 

1.  Mi[M'/x]  ::  S;  4';  Ei;r  {k  says  r)  o  [^1,^2]  (i-h.  on  1st  premise) 

2.  M2[M'/x]  ::  S;  4';  El;  P,  y  :  A:  claims  r  o  [u'^,u'^  ^  r'  o  [u'(,  u'2] 

(i.h.  on  2nd  premise) 

3.  (pf.saysE  (Mi[M7x])  ([y]M2[M7x]))  ::  S;4';E;;r  ^  r'  o  [u'(,u'2] 

(Rule  (saysE)  on  1  and  2) 

4.  (pf_saysEMi  ([y]M2))[M7a;]  =  pf_saysE  (Mi[M7a:])  ([y]M2[M7x])  (Definition) 

Proof  of  (2) 


Case. 


a  =  k' ,  Ub,  Ue 

4'  7  ^^1  ^  ■*^1  4'  7  ^2  <  M2  4'  7  Wi  <  Mf,  \=  Ue  <  U2  4'  7  A:  b  A;' 

X  ::  S;  4';  E;  P,  x  :  k  claims  s  o  [mi,  M2]  s  o  [m7  m^] 


claims 


1.  M'  ::  S;  E;  P]  TllidE,  s  o  [mi,  M2] 

2.  M' ::  S;^;E;r s  o  [mi,M2] 


3.  4'  7  (A,  ^*1,^*2)  >  « 
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(Assumption) 
(Weakening  on  1) 
(Premises  3-5) 


4.  M'  ::  ^  so  [ui,U2] 

5.  4'  ^  ?xi  <  u'l  and  'I'  ^  n2  <  U2 

6.  M'  ::  S;^;E;r  ^  so  [u'^^u'^] 

7.  x[M'/x\  =  M' 


(Lemma  A.l  on  2  and  3) 
(Premises  1  and  2) 
(Lemma  A. 3  on  4  and  5) 
(Definition) 


Case. 


M  ::  S;  4/;  A;  r| ,  a;  :  fc  claims  s  o  [ui,  M2] 


k' , 


^1,  U2] 


(pf  _saysl  M)  ::  S;  4';  A;  F,  a;  :  fc  claims  s  o  [mi,  M2]  (A:'  says  r)  o  [m(,  m^] 


—say  si 


1.  (rj)j  =  rj  (Definition) 

2.  M' ::  S;  4';  A;  (rj )  j  s  o  [mi,  M2]  (Assumption  and  1) 

k^  Xi!  xiJ 

3.  M[M'/x]  ::  S;'I';£';rj  —  ->  r  o  [u'i,u'<2\  (i.h.  on  premise  and  2) 

4.  (pf_saysl  {M[M' /x]))  ::  S;  4';  A;r  (/c'  says  r)  o  [u'i,u'^  (Rule  (saysl)  on  3) 

5.  (pf_saysl  M)[M' /x]  =  pf _saysl  {M[M' /x\)  (Definition) 


□ 


B  Proof  Verification  and  Generation  of  Procaps 

This  appendix  formalizes  the  verifier  for  BL’s  proofs  that  PCFS  uses.  Let  C  denote  a 
judgment  of  the  form  4^  j=  c  (the  judgment  may  or  may  not  hold)  and  C  denote  a  set 
of  such  judgments.  \=  C  means  that  for  each  (4'  ^  c)  G  C,  it  is  the  case  that  4'  ^  c 
holds.  Further  let  i  denote  a  set  of  interpreted  predicates.  E  \=  i  means  that  for  each 
i  £  i,  E  \=  i.  In  the  following,  we  first  discuss  a  general  proof  verification  procedure  for 
BL’s  proofs  and  then  show  how  it  is  specialized  to  PCFS. 

B.l  A  General  Proof  Verifier  for  BL 

We  construct  a  bidirectional  proof  verifier  for  BL  formalized  using  two  verification 
judgments:  M  ::  S;4';A;F  s  o  [mi,M2]  \  C]i  (checking  judgment),  and  M  :: 
S;  4^;  A;  F  <t=  so  [mi,  M2]  \  C;i  (synthesis  judgment).  The  intent  of  both  judgments  is 
that  \i\=  C  and  E'  ^  i,  then  M  ::  S;  4^;  A,  E']  F  s  o  [mi,  M2]  in  BL’s  natural  deduction 
system  (Figures  4  and  5).  However,  s  o  [mi,M2]  is  an  input  to  the  verification  procedure 
in  the  checking  judgment,  and  an  output  of  the  procedure  in  the  synthesis  judgment. 
M,  S,  4',  E,  F,  a  are  inputs  in  both  cases,  whereas  C,  i  are  always  outputs. 

The  output  C  is  a  non-deterministically  chosen  subset  of  the  constraint  judgments 
on  which  the  correctness  of  the  proof  depends.  The  non-determinism  is  deliberate;  in 
Section  B.2  we  show  how  the  non-determinism  is  resolved  when  the  verifier  is  used  in 
PCFS,  and  use  theorems  from  this  section  in  that  specific  context.  Figures  6  and  7  list 
the  rules  for  the  checking  judgment,  whereas  Figure  8  lists  the  rules  for  the  synthesis 
judgment.  The  notation  Ci  ixi  C2  =  C  means  that  Ci  and  C2  are  a  non-deterministically 
chosen  disjoint  partition  of  C.  All  rules  are  implemented  backwards:  the  proof  term 
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Ml  ::  E;  r  Si  o  [ui,U2]  '\  Ci',ii  M2  ::  E;  E;  F  S2  o  [1/1,  U2]  '\  C2',i2 
(pf -conjl  Ml  M2)  ::  E;  'F;  i?;  F  Si  A  S2  o  [ui,U2\  \  Ci ,  CS;  *1,  *2 

M  ::  E;'I';£;F  ^  o  [ui,U2\  \  C\i 


AI 


(pf  _disjll  M)  ::  E;  'F;  E;  F  si  V  S2  o  ["Ui,  ^2]  \  <5;  * 

M  ::  E;'I';E;F  ^  S2  o  [ui,U2\  \  C;? 
(pf_disjI2  M)  ::  E;  'F;  E;  F  si  V  S2  o  [ni,  112]  '\  C',i 


-Vll 


,VI2 


M  ::  E;  'F;  E;  F  ■^=  si  V  S2  o  [111, 112]  \  Ci;  ii  Mi  ::  E;  'F;  E;  F,  x  :  si  o  [iii,  112]  s'  o  Uj]  \  C2;  12 
M2  ::  E;  E;  F,  j/  :  S2  o  [111, 112]  s'  o  112]  \  C3;  *3 
(pf.disjE  M  ([x]Mi)  (MMa))  ::  E;^;E;F^  s'  o  [ni,«^]  \  cTi ,  C2,  C3;  ii ,  *2,  *3 

M  ::  E;^;E;F  ±  o  [111,112]  \  C;  * 


VE 


-TI 


(pf  _topI)  ::  E;  E;  F  T  o  [111 , 112]  S’  (pf  _botE  M)  ::  E;  E;  F  s  o  [ti^,  112]  \,  C;i 

M  ::  E,  111 :time,  ii2:time;  iF,  111  <  vi,V2  <  112;  E;  F,  x  :  si  o  [ui,  112]  S2  o  [ui ,  112]  \  C;  i 


-±E 


(pf  _impl  ([x][iii][i12]M))  ::  E;  E;  F  si  D  S2  o  [111 , 112]  \  C?;  * 
M  ::E,ii:cr;'F;E;F  s  o  [ui ,112]  \  C;i 


Ol 


(pf  _f  oralll  ([ii]M))  ::  E;  E;  F  Vv.a.s  o  [ui  ,112]  \  C;  i 
M  ::  E;^;E;F  s[i/ii]  o  [111,112]  \  C; i  E  h  t  :  it 


.VI 
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(pf  _existsl  t  M)  ::  E;  iF;  E;  F  3ii:(t.s  o  [111, 112]  \  C;  i 

Ml  ::  E;  iF;  E;  F  «J=  3ii:(T.s  o  [hi  ,112]  \  Ei ;  ii  M2  ::  E,ii:(t;'F;E;F,x  :  s  o  [111, 112]  s'  o  [iij ,  ii^  \  C2;  *2 
(pf  .exist sE  Ml  ([11]  [x]M2))  ::  E;  iF;  E;  F  s'  o  [11  j ,  ii^  \  Ci ,  C2;  ii ,  *2 


3E 


Figure  6:  BL:  Proof  verification  checking  rules,  Part  1 


to  be  verified  is  matched  with  the  conclusion  of  a  rule,  and  the  premises  established 
recursively.  Observe  that,  with  the  exception  of  the  rule  (CS)  in  Figure  7,  only  one 
other  rule  will  apply  to  any  given  proof  term  and  hypotheses. 

Since  bidirectional  proof  checking  is  standard,  we  describe  only  some  of  the  rules 
briefly.  Checking  rules  for  proof  terms  that  introduce  connectives  follow  a  similar  tem¬ 
plate.  We  explain  only  one  representative  case  here:  (Al)  from  Figure  6.  This  rule  states 
that  in  order  check  that  pf.conji  Mi  M2  establishes  the  judgment  si  A  S2  o  [ui,U2] 
(conclusion  of  the  rule),  we  must  check  that  Mi  establishes  si  o  [ui,U2]  (first  premise) 
and  that  M2  establishes  S2  o  [ui,U2]  (second  premise).  The  outputs  of  the  premises 
Ci;  ii  and  C2',  12  are  combined  to  form  the  output  of  the  whole  verification:  Ci,  (72;  ii,  ^2- 
Checking  rules  for  proof  terms  that  eliminate  a  connective  are  more  interesting.  In  these 
cases  the  principal  judgment  is  synthesized,  not  checked.  For  example,  in  the  rule  (VE) 
from  Figure  6,  the  first  premise  synthesizes  the  judgment  si  V  S2  o  [ui,U2\  from  the 
proof  term  M.  The  obtained  formulas  si  and  S2  are  then  used  to  check  the  two  proof 
terms  Mi  and  M2. 

The  rule  (interl)  from  Figure  5  corresponds  to  two  checking  rules  in  the  verifier, 
named  (interll)  and  (interI2)  in  Figure  7.  If  the  interpreted  predicate  i  checks  in  E, 
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M  ::  S;'J;E;r  s  o  [ui,U2]  \  C;? 

(pf  _atl  M)  ::  S;  'I';  E\  F  (s  @  [ui,U2])  o  [n^,  \  C;  i 

Ml  ::  S;^;£;r  (s  @  [«i,-!i2])  o  \  C?L;ii 

M2  ::  S;^;E;r,a:  :  s  o  [111,112]  s'  o  [u'(,u'^]  \  C2;*2 
- Z; - — - — - —  @E 

(pf_atE  Ml  ([x]M2))  ::  S;^;E;r  s'  o  [<, ii[j']  \  Ci,C2;ii,i2 


M  ::  S;'I';E;r|  s  o  [111,112]  \  C;  ? 

- zrz.saysl 

(pf.saysl  M)  ::  S;  ^*1  F  {k  says  s)  o  [wi,  U2]  \  C;  i 

Ml  ::  S;  ’F;  E]  F  4=  (/c  says  s)  o  [ui,  U2]  \  01;^! 

M2  S;^;£';F,a:  :  k  claims  s  o  [ui ,  U2]  o  [u'l ,  ^2]  \  ^2;  ^2 

- - - — - saysE 

(pf_saysE  Mi  ([x]M2))  ::  S;^;E;F  ^  s'  o  [u^^u'^]  \  Ci,C2;n,i2 


- - ^interll  “  - ^ - — ~interI2 

(pf  _sinj  1)  ::  E;  E;  F  i  o  [ui  ,U2]  \  ■;  ■  (pf  _sinj  I)  ::  E;  E;  F  i  o  [ui  ,U2]  \  ^ 

Ml  ::  E;^;E;r  1  o  [111,112]  \  Ci;ii  M2  ::  S;^;E,i;r  ^  s'  o  [ii'i,ii[,]  \  C2;i2 

- - — - — - — - -interE 

(pf  _sinjE  Ml  M2)  ::  S;  'E;  F  s'  o  [u'j^,  iij]  \  Ci,  C2;  *1,  *2 

Cl  ixi  C2  =  ('E  ]=  c)  [=  Cl 

- - —  consl 

(pf_cinjl)  ::  E;  E',  F  c  o  [ui,  112]  \  C2;  ■ 

Ml  ::  E;  'E;E;F  c  o  [111,112]  \  Ci;i1  M2  ::  E;'E,c;E;F  ^  s'  o  [tii,ii2]  \  C2;i2 

- - — - — - — - - consE 

(pf  _cinjE  Ml  M2)  ::  E;  'F;  E;  F  s'  o  [u'-^ ,  u^]  \  Ci ,  C2;  ^i,  ^2 

M  ::  E;^;£;;F  s  o  [111,112]  \  C;?  Ci  C<1  C2  =  ('E  [=  m  <  ii'i),  ('E  [=  ii(.  <  112)  ^  <^1  CS 

M  ::  E;^;£;F  ^  s  o  [iii,ii2]  \  0,02,1 


Figure  7:  BL:  Proof  verification  checking  rules,  Part  2 


(interll)  is  used  and  the  output  is  empty.  Otherwise,  i  is  written  to  the  output  (rule 
(interI2)).  When  the  verifier  is  used  in  PCFS,  E  is  generally  empty,  so  in  practice,  i 
always  gets  written  to  the  output  (and  then  to  the  procap). 

Synthesis  rules  (Figure  8)  apply  to  some  proof  terms  that  eliminate  connectives  and 
to  hypotheses  (rules  (hyp)  and  (claims)).  The  only  non-trivial  rule  here  is  (dE).  It  states 
that  in  order  to  synthesize  the  judgment  proved  by  a  proof  term  pf  _impE  Mi  M2  u'^ 
we  should  first  synthesize  the  judgment  si  D  S2  o  [ui,U2]  proved  by  Mi  (first  premise). 
Next,  we  should  check  that  M2  proves  si  o  [u'i,u'^  (second  premise)  and  that  [u'i,u'^  is 
a  subset  of  (constraints  ('k  ^  ui  <  u'l)  and  ('k  \=  u'2  <  U2))-  If  all  these  hold, 

then  pf  _inipE  Mp  M2  u\  proves  the  judgment  S2  o  [u'^,  ^2). 

In  both  the  checking  and  synthesis  rules,  if  a  set  of  constraint  judgments  needs  to  be 
checked  in  a  rule,  then  this  set  is  split  non-deterministically  into  two  sets,  one  of  which 
is  checked  immediately,  and  the  other  of  which  is  written  to  the  output.  This  happens  in 
rules  (consl),  (CS),  (claims)  and  (dE).  It  is  expected  that  the  output  judgments  will  be 
checked  later  (e.g.,  in  PCES,  the  output  judgments  are  written  in  a  procap  and  checked 
whenever  the  procap  is  checked). 

The  rule  (CS)  in  Eigure  7  allows  the  verifier  to  move  from  a  checking  judgment  to 
a  synthesis  judgment  without  changing  the  proof  term.  This  shift  can  be,  and  must 
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-hyp 


X  ::  :  s  o  [ni,  112]  <=  s  o  [ui ,  M2]  \i 

a  =  k,  ui,,  Ug  Cl  ixi  C2  =  (^  1=  Ml  <  Uf,),  ('5  |=  Ug  <  M2),  \=  k'  ^  k)  \=  Ci 

X  ::  :  k'  claims  s  o  [mi  ,  M2]  <=  s  o  [mi,  M2]  \  C2;  ■ 

M  ::  S;  'h;  i?;  r  4=  si  A  S2  o  [mi  ,  M2]  \  C;  i 


(pf -ConjEl  M)  ::  S;  \1/;  E\  F  4=  si  o  [mi,  M2]  \  C;  i 

M  ::  S;  'F;  _E;  F  si  A  S2  o  [mi,  M2]  \  C-,i 
(pf  _conjE2  M)  ::  S;  'F;  C;  F  <^=  S2  o  [mi,  M2]  \|  C;  i 


AEl 


,AE2 


claims 


Ml  ::  S;  ^F;  E;  F  si  D  S2  o  [mi,  M2]  \  Ci;  ii 

M2  ::  S;^;E;F  ^  si  o  [m'i,m^]  \  C2;i2  C3  ixi  C4  =  ('I'  ]=  mi  <  Mi),('F  \=  u'2  <  M2) 

(pf -impE  Ml  M2  u'l  M2)  ::  S;  iF;  E;  F  S2  o  [m'j^,  Mj]  \  Ci,  C2,  C?4;  *1,  *2 

M  ::  S; -F;  E;  F  4^  Vm:o-.s  o  [mi,  M2]  \  C;  ?  S  h  t  :  tr 


(pf  _f  orallE  M  t)  ::  S;  'F;  E;  F  4=  s[f/M]  o  [mi,  M2]  \  C;  * 


-VE 


\=  C3 


DE 


Figure  8:  BL:  Proof  verification  synthesis  rules 

be,  applied  when  the  proof  term  M  matches  the  proof  term  in  the  conclusion  of  some 
rule  in  Figure  8.  Generally,  bidirectional  proof  verifiers  also  allow  a  shift  in  the  other 
direction  -  from  synthesis  to  checking  -  via  an  explicit  proof  term  constructor.  In  our 
implementation  we  do  not  allow  this  coercion.  The  consequence  of  this  restriction  is  that 
our  verifier  can  only  check  normal  proof  terms  (a  proof  term  is  normal  if  it  does  not 
contain  any  elimination  constructor  immediately  outside  an  introduction  constructor). 
While  it  is  easy  to  avoid  this  restriction  by  allowing  the  explicit  coercion,  we  do  not 
do  so  here  since  our  proof  search  tool  constructs  normal  proofs  only.  Further,  normal 
proofs  are  complete:  any  hypothetical  judgment  that  has  a  proof  also  has  a  normal 
proof.  Proof  of  the  latter  result  is  based  on  a  sequent  calculus  presentation  of  BL,  which 
is  beyond  the  scope  of  this  paper. 

Another  important  point  concerns  the  scope  of  parameters  in  the  checking  rules  (VI) 
and  (3E)  of  Figure  6.  In  each  case,  the  premise  introduces  a  new  parameter  v.a,  which 
may  appear  free  in  the  output  -  (7;  i  for  (VI)  and  Gi,  6*2;  ii,  ^2  for  (3E).  As  mentioned 
in  Appendix  A,  decision  procedures  for  solving  constraints  and  interpreted  predicates 
treat  such  parameters  universally,  e.g.,  in  the  case  of  (VI),  if  C  is  found  to  hold  then 
C[t/v\  would  also  hold  for  every  ground  term  t.  To  ensure  that  parameters  introduced 
in  different  branches  of  the  verification  do  not  conflict  in  the  outputs,  we  also  assume 
implicitly  that  all  parameters  introduced  during  verification  are  unique. 

The  following  lemma  establishes  that  this  verification  procedure  is  sound,  i.e.,  any 
proof  it  verifies  is  valid  in  BL’s  natural  deduction  system  subject  to  some  conditions. 

Lemma  B.l  (Verification  Soundness).  Suppose  that  \=  C  and  E'  \=  i.  Then 

1.  M  ::  S;  'L;  E;  F  =%  s  o  [?xi,  U2]  \  C;i  implies  M  ::  T,]  ^  ]  E ,  E']  F  s  o  [tti,  7x2]  \ 

C-fi 

2.  M  ::  S; E;  F  s  o  [ui,  U2]  \  C;i  implies  M  ::  S; E,  E';  F  s  o  [^1,^2]  \ 
C]i 
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Proof.  The  proof  follows  by  a  simultaneous  induction  on  the  given  derivations.  We  show 
some  representative  cases  below. 


Case. 


Ml  ::  S;  T;  £1;  r  si  o  [ui,  M2]  \  Ci;  ii 


(pf_conjI  Ml  M2)  S;  T;  E;  T 


S2  O  [Mi,M2j  \ 


M2  ::  S;T;£;;r _ 

Si  A  S2  o  [mi,M2]  \  C'i,C'2;il,Z2 


-AI 


1.  hCl,C2 

2.  ^  Cl  and  \=  C2 

3.  E'  \=  ii,i2 

4.  E'  ^  ii  and  E'  \=  12 

5.  Ml  ::  S;  'h;  E,  E']  T  si  o  [m,  U2] 

6.  M2  ::  'P]'^-,E,E'-,T  ^  S2  o  [ui,U2] 

7.  (pf_coiijI  Ml  M2)  ::  S;  ih;  i?,  ill';  T 


(Assumption) 
(Definition) 
(Assumption) 
(Definition) 
(i.h.  on  1st  premise,  2,  4) 
(i.h.  on  2nd  premise,  2,  4) 
Si  A  S2  o  [mi,M2]  (Rule  (Al)  on  5,6) 


Case. 


E  h  i 


(pf_sinjl)  ::  T,;'i>;E;T 


- interl 1 

i  o  [mi,M2]  \  •;  • 


1.  E^i 

2.  E,E' 

3.  (pf  _siiijl)  ::  S;  'I';  E,  E';  T  i  o  [tti,  M2] 

Case.  - - - interI2 

(pf_sinjl)  ::  Y.;^;E;T  i  o  [ui,U2]  \  •;* 


(premise) 
(Weakening-state) 
(Rule  (interl)  on  2) 


1.  E' 

2.  E,E' 

3.  (pf  _siiijl)  ::  S;  'k;  E,  E';  T  i  o  [mi,  M2] 


(Assumption) 
(Weakening-state) 
(Rule  (interl)  on  2) 


Case. 


Ml  ::  [mi,M2]  \  Ci;fi  M2  ::  S];4';A,i;r  ^  s'  o  Ki,m'2]  \ 

(pf_sinjE  Ml  M2)  ::  S;  T;  A;  T  s'  o  [m'i,  M2]  \  Ci,  C2;  ii,  ia 


interE 


1.  hCl,C2 

2.  E'  ^  ii,  i2 

3.  Ml  ::  S;  'k;  E,  E';  T  i  o  [mi,  M2] 

4.  M2  ::  S;  E,  i,  E';  T  ^  s'  o  [m'i,  M'2] 

5.  (pf -sinjE  Ml  M2)  ::  S;  'k;  E,  E']  T  — >  s'  o  |m'i  ,  m: 
Cl  M  C2  =  (T  h  c)  h  Cl 


1)  “'2J 


Case. 


(pf_cinjl)  ::  S;4';  £;;r  co  [mi,M2]  \  C2] 


consi 


(Assumption) 
(Assumption) 
(i.h.  on  1st  premise,  1,2) 
(i.h.  on  2nd  premise,  1,2) 
(Rule  (interE)  on  3,4) 
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1. 

2. 

3. 

4. 

5. 


Cl  M  C2  =  (^  N  c) 


4^  ^  c 

(pf  _ciiijl)  ::  S;  4';  E,  E';  F  c  o  [ui,  ti2] 


(2nd  premise) 
(Assumption) 
(1st  premise) 
(1,2,3) 

(Rule  (consi)  on  4) 


Case, 


Ml  ::  S;  A;  r  c  o  [ui,U2]  \  Ci]  H  Ma  ::  S;  c;  A;  T  ^  s'  o  [E^u'^]  \  C2]  »2 
(pf_cinjE  Ml  M2)  ::  S;4';  A;r  s'  o  [u\,u'2]  \  Ci,C2',ii,h 


consE 


1. 

2.  C'  ^  R,i2 

3.  Ml  ::  S;  'I';  E,  E']  T  ^  c  o  [tti,  tt2] 

4.  M2  ::  S;  c;  E,  E';  T  ^  s'  o  [u'^^u'^] 

5.  (pf_cinjE  Ml  M2)  ::  S;4';£', C';r  ^  s'  o  [u'i,u'2\ 


(Assumption) 
(Assumption) 
(i.h.  on  1st  premise,  1,2) 
(i.h.  on  2nd  premise,  1,2) 
(Rule  (consE)  on  3,4) 


M  ::  S;4';E;r 


s  o  [rti,  ri2]  \  C;  i 


Cl  CXI  C2  =  (4' ^  ui  <  u'l),  (4' ^  ■u'2  <  ^2) 

Case.  - - - ^ - CS 

M  ::  S;  E;  r  ^  s  o  [n'l,  n'2]  \  C,  C2C 

1.  hC,C2 

2.  E'  '^i 

3.  M  ::  S;  4^;  E,  E']  E  s  o  [tti,  ti2] 

4. 

5.  Cl  M  C2  =  (4'  1=  rti  <  tt'i),  (4^  \=  u'2  <  U2) 

6.  4^  ^  wi  <  ti'i  and  4^  ^  n'2  <  U2 

7.  M  ::  S;  C,  E';  E  A  s  o  [u'^^u'^] 

Case 


a;  ::  S;  4';  A;r,x  :  s  o  [ui,U2]  <;=  s  o  [mi,M2]  \  •; 

1.  4^  ^  Ml  <  tti  and  4^  ^  M2  <  M2 

2.  X  ::  S;  4^;  E,  E';  T,x  :  s  o  [mi,  M2]  s  o  [mi, M2] 


hyp 


(Assumption) 
(Assumption) 
(i.h.  on  1st  premise,  1,2) 
(3rd  premise) 
(2nd  premise) 

(1,4,5) 

(Theorem  A. 3  on  3,6) 

(Refl-time) 
(Rule  (hyp)  on  1) 


Case. 


Ml  ::  S;4';  A;r  Si  D  S2  o  [mi,U2]  \  Ci;R  M2  ::  S;  T;  A;r  si  o  [u'i,uy  \  CaCa 

_ _ C3  tx]  C4  =  (T  (=  Ml  <  m'i),  (T  ^  u'2  <  M2)  1=  C3 

(pf  _impE  Ml  M2  m'i  M2)  ::  S;  T;  E]  T  S2  o  [m'i,  m^  \  Ci,  C2,  C4;  R,  Z2 


DE 


1.  hCi,C2,C4 


(Assumption) 
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2.  N^s 

3.  \=  C3,  Ci 

4.  C3  M  C4  =  (4^  1=  <  Ui),  (4'  \=  u'2  <  U2) 

5.  4^  ^  Ml  <  u'l  <  u'l  and  4^  ^  M2  —  "^'2  —  ^2 

6.  E'  \=  ii,i2 

7.  Ml  ::  S;  4';  E']  T  si  D  S2  o  [mi,  M2] 

8.  M2::J^;'i>;E,E'-,r  ^  sio[u'i,u'2] 

9.  (pf_inipE  Ml  M2  u'l  u'2)  T,-,^-,E,E'-,T  - 


(4th  premise) 
(1,2) 

(3rd  premise) 
(3,4,Refl-time) 
(Assumption) 
(i.h.  on  1st  premise,  1,  6) 
(i.h.  on  2nd  premise,  1,  6) 
S2  o  [u'l,  u'2]  (Rule  (dE)  on  7,8,5) 


□ 


We  also  need  the  following  substitution  lemma  in  order  to  prove  Theorem  4.1. 

Lemma  B.2  (Term  substitution). 

1.  If  M  ::  S,  m:it;  4^;  E;  T  =%  s  o  [mi,M2]  \  C',i  and  T,  \-  t  :  a,  then  M[t/v]  :: 
T,]'ii[t/v]]E[t/v]]T[t/v]  s[t/v]  O  [Ml[t/M],M2[t/M]]  \  C[t / v]]  i[t / v] . 

2.  If  M  ::  S,  m:(t;  4^;  E;  T  s  o  [mi,M2]  \  C',i  and  T,  \-  t  :  a,  then  M[t/v]  :: 
T,;'if[t/v]-,E[t/v]-,T[t/v]  s[t/v\  o  [Mi[t/M],  M2[t/M]]  \  c[t/v\-,i[t/v\. 

Proof.  By  simultaneous  induction  on  the  given  derivations,  and  case  analysis  of  the  last 
rules.  For  the  rules  (aE),  (claims),  and  (consi),  the  assumption  (Substitution-cons)  is 
needed.  For  the  rule  (interl),  (Substitution-state)  is  needed.  □ 

B.2  Proof  Verification  in  PCFS 

PCFS  uses  a  specialized  version  of  BL’s  non-deterministic  verifier  described  above. 
As  mentioned  in  Section  4,  in  PCFS,  the  problem  is  to  check  that  M  ::  S;-;£';r  — > 
auth(/c,  /,  7/,  m),  where  a  is  a  view  made  of  fresh  constants,  u  is  the  time  of  access,  and 
E  is  the  environment  at  time  m.  Since  neither  u  nor  E  is  known  when  verification  is  done, 
the  verifier  instead  tries  to  check  that  M  ::  S,  ctimeitime;  P  auth(/c, /,  r/,  ctime), 
where  ctime  is  a  symbolic  constant  that  represents  the  actual  time  of  access. 

Any  constraints  containing  ctime  encountered  during  verification  are  output  from  the 
verification  procedure  (on  the  right  of  \);  others  are  checked  immediately.  This  method 
is  sound  because  Lemma  B.l  shows  that  any  strategy  for  deciding  which  constraints  to 
check  during  verification,  and  which  to  output  is  correct.  The  constraints  written  to  the 
output  are  then  also  written  in  the  procap  produced,  and  get  checked  when  the  procap 
is  verified.  (At  that  time,  ctime  is  substituted  by  the  actual  time  of  access.)  More 
precisely,  whenever  the  verifier  needs  to  construct  Ci  and  C2  such  that  Ci  cxi  (72  =  C* 
(rules  (aE),  (claims),  and  (consi)),  it  sets  Ci  to  those  judgments  4'  |=  c  in  (7  that  do 
not  contain  ctime.  C2  contains  the  remaining  judgments.  Ci  is  checked  immediately  by 
the  verifier,  whereas  C2  is  written  to  the  output  procap. 
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Summary  of  proof  verification  in  PCFS.  Proof  verification  in  PCFS  can  be  sum¬ 
marized  as  follows.  The  verifier  is  given  a  proof  term  M,  S  (from  a  trusted  file),  P 
(in  the  form  of  certificates),  k,  /,  and  r].  It  tries  to  check  the  proof  by  establishing 
the  judgment  M  ::  S,  ctime:time;  •;  •;  P  auth(A:,  /,  rj,  ctime)  \  C;i  for  some  C  and  i, 
resolving  non-determinism  in  splitting  constraint  judgments  as  described  above.  If  this 
succeeds,  it  issues  the  procap  {ip,  C,  i,  H)  where  -ip  =  />  v)  H  is  a  cryptographic 

signature. 

The  procap  can  be  checked  during  access  at  time  u  in  environment  E  by  ensuring 
that  E  \=  i  and  that  |=  C[M/ctime].  We  now  show  that  these  checks  are  sufficient  to 
show  that  M  ::  T,]-]E]T  auth(fc, /,  r/,  u),  i.e.,  the  authorization  is  valid  at  the  time 
of  aeeess. 

Theorem  B.3  (Soundness  of  enforcement;  Theorem  4.1).  Suppose 
M  ::  S,  ctime:time;  T  auth(A:, /,  r/,  ctime)  \  where  ctime  is  a  new  eonstant. 
Let  u  be  a  (later)  point  of  time  at  whieh  the  environment  is  E,  and  suppose  that: 

1.  \=  Cpa/tme] 

2.  E  \=  i 

Then,  M  ::  S;  •;  F;  P  ^  auth(/c,  /,  r/,  u) . 

Proof.  We  reason  as  follows: 

\C]i  (Assumption) 

i  (Lemma  B.2;  ctime  is  fresh) 
(Assumption) 
(Assumption) 
(Lemma  B.l  on  2,3,4) 
□ 


1.  M  ::  S,  ctimeitime;  •;  •;  P  auth(/c,  /,  rj,  ctime) 

2.  M  ::  S;  •;  •;  P  auth(fe,  /,  rj,  u)  \  (7[ri/ctime]; 

3.  \=  C[u/t\me] 

A.  E'^i 

5.  M  ::  S;  E]T  auth(A:,  /,  rj,  u) 
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